bug#3303: delete-frame raises old (invisible) frame

[David Reitter]

On May 18, 2009, at 10:46 PM, Stefan Monnier wrote:
> 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"?

I enter a key sequence, e.g. C-x 5 2, and Emacs does not react.
I select a menu item from the Options menu, and Emacs does not react.

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

This does not happen all the time when there is only one frame and it  
is invisible, but it is perfectly reproducible for me with the code I  
sent.

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

Ah, now I see why you don't understand.

The doc string says that the system may select it, and that's exactly  
what happens here on Cocoa/OSX.
This reproduces the problem just as well:

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

i.e. we end up with a visible frame, the frame that we hid initially.

smime.p7s
Description: S/MIME cryptographic signature