GNU bug report logs - #3303
delete-frame raises old (invisible) frame

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Reitter <david.reitter <at> gmail.com>
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, 3303 <at> debbugs.gnu.org
Subject: bug#3303: delete-frame raises old (invisible) frame
Date: Mon, 18 May 2009 22:46:19 -0400

>>> Precisely for this reason is the patch not sufficient.
>> 
>> I do not understand.
>> 
>>> When there is a hidden frame, and you delete the only other existing
>>> frame,
>>> we end up in a situation where there is no key window to receive the
>>> event,
>>> and all events (including menu items) are simply dropped.
>> 
>> Could you explain concretely why it's a problem.

> Well, if you have only hidden frames this way, you will receive no key
> events:

> (progn
>   (make-frame-invisible (selected-frame) t)
>   (make-frame)
>   (delete-frame (selected-frame) t))

> The Lisp level doesn't even see menu events.

You just repeated what you had already written.  It's not concrete
enough for me to understand.  What means "receive no key event" or "Lisp
doesn't even see menu events"?

> A little more investigation shows that we get the event in keyDown:, but we
> discard it in this code:

>  if (![[self window] isKeyWindow])
>    {
>      /* XXX: There is an occasional condition in which, when Emacs display
>          updates a different frame from the current one, and temporarily
>          selects it, then processes some interrupt-driven input
>          (dispnew.c:3878), OS will send the event to the correct NSWindow,
> but
>          for some reason that window has its first responder set to the
> NSView
>          most recently updated (I guess), which is not the correct one. */
>      if ([[theEvent window] isKindOfClass: [EmacsWindow class]])
> 	      [(EmacsView *)[[theEvent window] delegate] keyDown: theEvent];
>      return;
>    }

I think I understand: you mean that when there's only one frame and it's
invisible, we actively ignore *all* events (rather than the OS refusing
to deliver them to us), and hence Emacs becomes completely unresponsive.
Yes, that bug would need to be fixed.

> Even with this workaround/fix, now we're back to the other problem with this
> bit of code:

> (progn
>   (make-frame-invisible (selected-frame) t)
>   (make-frame)
>   (delete-frame (selected-frame) t)
>   (make-frame)
>   (sit-for 0)
>   (delete-frame (selected-frame) t))

I still don't understand the above code, for the reason already
explained: you use `selected-frame' in a way that seems to imply that
you expect make-frame to change the selected-frame, where its docstring
says explicitly that it doesn't.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.