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

[David Reitter]

On May 18, 2009, at 10:56 PM, David Reitter wrote:
> 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.


OK, I have traced this a bit further and reduced it to this:

(progn
  (setq aa1 (selected-frame))
  (make-frame-invisible (selected-frame) t)
  (setq aa2 (selected-frame)
        aa2v (frame-visible-p (selected-frame)))
  (sit-for 1)
  (setq aa3 (selected-frame)
        aa3v (frame-visible-p (selected-frame))))

(list aa1 aa2 aa2v aa3 aa3v)


After evaluating the first sexp (Emacs -Q), one can see that the  
selected frame doesn't change at any point.  But aa2v is nil  
(correctly so), and aa3v is suddenly t.

This does not happen with Emacs 22/Appkit.  Both aa2v and aa3v are  
nil, as they should.

Could someone check what the behavior is in another port (of 23)?

I believe that this is the cause of the problems we're after.
In the previous examples, when delete_frame calls do_switch_frame, the  
frame is already deemed visible, even though it hasn't been made  
visible through the appropriate system call.  The above example  
demonstrates that something (in the event loop, presumably) sets frame  
visibility.
It is not a call to FRAME_SAMPLE_VISIBILITY, which is done in `frame- 
visible-p' anyways.  (The NS port always sets f->async_visible and  
lets this macro set ->visible later.)

smime.p7s
Description: S/MIME cryptographic signature