bug#69525: 30.0.50; MacOS: New warnings on stderr

[Alan Third]

On Mon, Mar 04, 2024 at 02:48:52PM +0100, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Sun, Mar 03, 2024 at 06:36:29PM +0100, Gerd Möllmann wrote:
> >> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >> 
> >> > Eli Zaretskii <eliz@gnu.org> writes:
> >> >
> >> >>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> >>> Date: Sun, 03 Mar 2024 17:18:42 +0100
> >> >>>
> >> >>> The following warnings are printed to stderr, which I haven't seen
> >> >>> previously. Maybe canBecomeKeyWindow should be implemented?
> >> >>>
> >> >>> 2024-03-03 17:10:16.334906+0100 emacs[12805:61381] [Window] Warning: 
> >> >>> -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which 
> >> >>> returned NO from -[NSWindow canBecomeKeyWindow].
> >
> > Odd, Apple's documentation says:
> >
> >     The value of this property is YES if the window can become the key
> >     window, otherwise, NO.
> >     
> >     Attempts to make the window the key window are abandoned if the
> >     value of this property is NO. The value of this property is YES if
> >     the window has a title bar or a resize bar, or NO otherwise.
> >
> > Is there anything unusual about your frames?
> 
> Found out how to reproduce this with emacs -Q. In scratch, eval
> 
>   (make-frame (list (cons 'parent-frame (selected-frame))
>                   (cons 'no-accept-focus t)))
> 
> This looks to me like some function in ELPA package consult uses
> no-accept-focus t, so that nsterm.m returns NO from canBecomeKeyWindow.
> Consult with posframe seems to work anyway, so...

We should be able to create a frame without the system throwing out
errors, though. I wonder if this is something we're doing (like
makeKeyAndOrderFront being called on the new frame and it not checking
canBecomeKeyWindow) or if there's some other step we need to take to
prevent this. I'm fairly sure that I've never seen these warnings so
presumably they're new since 10.14.

-- 
Alan Third