bug#16967: frame related race condition

[martin rudalics]

>> When we get a SIZE_RESTORED message we have to make the frame visible.
>
> Well, yeah, no. I don't know why an invisible frame gets a
> SIZE_RESTORED message, but as long as Emacs thinks it's invisible, no,
> it shouldn't be made visible. The WM is at the service of Emacs, not
> the other way around.

No.  But the `make-frame' in

(let* ((c (selected-frame))
       (f (make-frame)))
  (sit-for 0)
  (select-frame-set-input-focus f)
  (sit-for 0)
  (delete-frame c))

should create a normally visible frame f.  The fact that this frame has
its visibility set to zero at the time you `delete-frame' c indicates
that we have a pretty awful bug.  The implications of this are
substantial because SET_FRAME_VISIBLE has to redisplay_other_windows and
if that is not done, the consequences are not restricted to the toy
scenario you gave.

Lately I frequently noticed that an Emacs frame that was for some time
hidden by other applications and subsequently became exposed by deleting
their windows was not redrawn and I would like to know whether this was
the reason.  ISTR that others noted the same or a similar misbehavior.

> Or are you saying that you find acceptable being unable to make an
> invisible frame?

No.  But we apparently have the problem that Emacs on Windows thinks
that a frame is invisible although it isn't.  And we have to find out
where this notion of invisibility gets introduced - maybe it's easy to
spot it, maybe, likely it's part of my pixelwise changes, and we can
withdraw my "fix" soon.  But till then we have to live with the
situation that on Windows invisible Emacs frames are visible :-(

martin