bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii <eliz@gnu.org>]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 11 Jul 2013 17:39:26 +0200
> Cc: 14841@debbugs.gnu.org
> 
> >>      On ttys and on Windows NT/9X, to avoid wasting effort updating
> >>      visible frames that are actually completely obscured by other
> >>      windows on the display, we bend the meaning of visible slightly:
> >>      if equal to 2, then the frame is obscured - we still consider
> >>      it to be "visible" as seen from lisp, but we don't bother
> >>      updating it.  We must take care to garbage the frame when it
> >>      ceases to be obscured though.  See SET_FRAME_VISIBLE below.  */
> >>   unsigned visible : 2;
> 
> > I don't see how this is related to the bug you describe.  Can you
> > elaborate why you think it is?
> 
> That's a trick question. I don't know, that's why I said "could be
> related". Why did I think so? Because the comment clearly describes a
> case where a frame is not "visible" (on the screen) and yet "visible"
> (to lisp).

But it doesn't say anything about frames created invisible.  It talks
about frames that are visible, but obscured.

> Also, because it does not seem a bug in make-frame (after make-frame,
> the frame has visibility = nil as expected); it is only noticeable
> after redisplay; or at least, after the command is finished, which
> suggests that redisplay was likely triggered.

Can you provide a recipe to reproduce this, starting with "emacs -Q"?