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

Previous Next

Packages: emacs, ns;

Reported by: David Reitter <david.reitter <at> gmail.com>

Date: Sat, 16 May 2009 01:15:04 UTC

Severity: normal

Merged with 3204

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #120 received at 3303 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
        Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 3303 <at> debbugs.gnu.org
Subject: Re: bug#3303: delete-frame raises old (invisible) frame
Date: Tue, 19 May 2009 22:07:00 -0400
[Message part 1 (text/plain, inline)]
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 (application/pkcs7-signature, attachment)]

This bug report was last modified 13 years and 288 days ago.

Previous Next


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