bug#67694: 30.0.50; tool-bar

[Alan Third <alan@idiocy.org>]

On Sat, Dec 16, 2023 at 02:15:05PM +0100, Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Konrad Podczeck <konrad.podczeck@univie.ac.at> writes:
> 
> > In nsterm.m, deleting the lines of code
> >
> >
> > #ifdef NS_IMPL_COCOA
> > if (! send_appdefined)
> >   {
> >   /* OS X 10.10.1 swallows the AppDefined event we are sending ourselves
> >        in certain situations (rapid incoming events).
> >        So check if we have one, if not add one.  */
> >     NSEvent *appev = [NSApp nextEventMatchingMask:NSEventMaskApplicationDefined
> >                                         untilDate:[NSDate distantPast]
> >                                            inMode:NSDefaultRunLoopMode
> >                                           dequeue:NO];
> >     if (! appev) send_appdefined = YES;
> >   }
> > #endif
> >
> > as done in commit 6acb3c5b05a7b9fb32a5336e1bb740f527571ae9 on
> > 23-09-11, seems to be incompatible with macos Sonoma or Monterey. In
> > both versions, and with both an M1 processor and an Intel one, I got
> > the following problem, with these lines of code removed. I have
> > pdf-tools installed, and via the code in windows.el, I have both the
> > pdf output and some latex source code to appear in their own frames. I
> > also have a managed to have a tool-bar in the frame showing the
> > pdf-outout, with an icon for going from one page to the next. Now if I
> > repeatedly click with the mouse on this icon very fast, then, after 3
> > to 5 clicks, the whole emacs.app begins to hang. This is not so with
> > the above lines of code still present in nsterm.m.
> 
> Could you describe the steps to reproduce this bug in more detail?  Does
> it happen only when using the pdf-tools package?
> 
> Starting from emacs -Q, I’ve installed the pdf-tools package (M-x
> package-install RET pdf-tools RET), but, after visiting a PDF file, I
> don’t see any tool-bar icons to go to the previous and next page in the
> PDF.

I hate this application defined event malarkey, but I was never able
to come up with a better solution. The problem described in the
removed comment certainly looks like an Apple bug, but if it is then
surely it would have been fixed by now.

Konrad, are you able to try changing the code thus (the line numbers
are probably wrong):

modified   src/nsterm.m
@@ -4604,10 +4604,16 @@ Function modeled after x_draw_glyph_string_box ().
                                    data1: value
                                    data2: 0];
 
-      /* Post an application defined event on the event queue.  When this is
-         received the [NXApp run] will return, thus having processed all
-         events which are currently queued.  */
-      [NSApp postEvent: nxev atStart: NO];
+      if (! nxev)
+        {
+          NSLog(@"Something has stopped us creating an event.");
+          send_appdefined = YES;
+        }
+      else
+        /* Post an application defined event on the event queue.  When this is
+           received the [NXApp run] will return, thus having processed all
+           events which are currently queued.  */
+        [NSApp postEvent: nxev atStart: NO];
     }
 }

See if the log message prints, and/or whether it solves the problem.

-- 
Alan Third