bug#67528: tool-bar

bug#67528: tool-bar

[Stefan Kangas]

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.
>
> Konrad Podczeck

Alan, what do you think?

bug#67528: tool-bar

[Alan Third]

package emacs
merge 67528 67694
thankyou

On Wed, Jan 10, 2024 at 09:39:54AM -0800, Stefan Kangas 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.
> >
> > Konrad Podczeck
> 
> Alan, what do you think?

We had a look at this in bug#67694, and I don't know. The code was
removed because it appeared to be causing a crash on startup, so if we
reinstate it we'll need to reopen that bug report (bug#65843).

I find it hard to believe the comment is right and this is a bug that
hasn't ever been fixed. I think it's more likely the actual culprit is
some timing issue in our own code, but that doesn't help as I don't
understand it. As for how this code causes the crash in 65843, I don't
understand that either.
-- 
Alan Third