A GTK-only problem when making frames invisible

A GTK-only problem when making frames invisible

[martin rudalics]

Dear people

For some time GTK builds of master here exhibit the following problem.
Run emacs -Q, insert the three following lines in *scratch*

(defvar frame (make-frame))
(make-frame-invisible frame)
(frame-visible-p frame)

and evaluate them line by line.  Here, the last evaluation returns
"icon" which is clearly wrong.  Running the same procedure with older
versions including the release candidate delivers "nil" which is
correct.

If a kind soul can reproduce the problem and has a sufficiently fast
machine, it would be nice if she could bisect this to find the offending
commit.  Here building takes more than an hour so I'm not very eager to
do that.  I have a left over build from 2016-11-23 which already
exhibits the problem so that commit should have occurred before that
date.

If anyone is interested in what happens, compare the results for running
the output of

xwininfo -root -tree -int

with gdb output of a breakpoint in xterm.c around

     case Expose:
       f = x_window_to_frame (dpyinfo, event->xexpose.window);

For the release session I get here:

   Parent window id: 0 (none)
      49 children:
      56623339 "*Messages*": ("emacs" "Emacs")  750x719+30+145  +30+145
         2 children:
         56623342 (has no name): ()  750x648+0+71  +30+216
            1 child:
            56623372 (has no name): ()  32000x32000+0+0  +30+216
         56623340 (has no name): ()  1x1+-1+-1  +29+144

(gdb) p event->xexpose.window
$9 = 56623339

For the trunk session (at least after 2016-11-23) I get here:

   Parent window id: 0 (none)
      49 children:
      58720484 "*Messages*": ("emacs" "Emacs")  750x719+65+-50  +65+-50
         2 children:
         58720487 (has no name): ()  750x648+0+71  +65+21
            3 children:
            58721343 (has no name): ()  1x1+-1+-1  +64+20
            58720516 (has no name): ()  32000x32000+0+0  +65+21
            58721338 (has no name): ()  14x612+736+0  +801+21
         58720485 (has no name): ()  1x1+-1+-1  +64+-51

(gdb) p event->xexpose.window
$5 = 58720487

Now x_window_to_frame produces no frame in the release session (IIUC
because the 56623339 "*Messages* window is the window manager window)
while it produces a frame (IIUC because window 58720487 is that frame's
edit window).  The subsequent code based on f not being zero contains an
assignment that is responsible for setting the "iconified" state.  Note
also that the release session *Messages* window has one child while that
of master has three.

Thanks in advance, martin

Re: A GTK-only problem when making frames invisible

[Stephen Berman]

On Sat, 04 Feb 2017 18:02:59 +0100 martin rudalics <rudalics@gmx.at> wrote:

> For some time GTK builds of master here exhibit the following problem.
> Run emacs -Q, insert the three following lines in *scratch*
>
> (defvar frame (make-frame))
> (make-frame-invisible frame)
> (frame-visible-p frame)
>
> and evaluate them line by line.  Here, the last evaluation returns
> "icon" which is clearly wrong.  Running the same procedure with older
> versions including the release candidate delivers "nil" which is
> correct.

When I execute your recipe, after the make-frame-invisible invocation
the new frame get minimized, i.e., is only represented on the desktop as
an entry in the task bar (or panel in KDE terminology), and the
frame-visible-p invocation returns t.  Is that expected?    

This is with KDE 4.14.9 and GNU Emacs 26.0.50.3 (x86_64-suse-linux-gnu,
GTK+ Version 3.16.7) of 2017-02-01 built on rosalinde
Repository revision: 5d61ef0de9a3f5b1be9e93465cb88aae995975ba
Windowing system distributor 'The X.Org Foundation', version 11.0.11601000
System Description:	openSUSE 13.2 (Harlequin) (x86_64)

Steve Berman

Re: A GTK-only problem when making frames invisible

[martin rudalics]

 > When I execute your recipe, after the make-frame-invisible invocation
 > the new frame get minimized, i.e., is only represented on the desktop as
 > an entry in the task bar (or panel in KDE terminology), and the
 > frame-visible-p invocation returns t.  Is that expected?

No.  The frame should disappear from the taskbar:

      On graphical displays, invisible frames are not updated and are
      usually not displayed at all, even in a window system’s "taskbar".

Can you try with an earlier version?  And is there any difference if, as
a second step, you do (iconify-frame frame) instead?

Thanks, martin

Re: A GTK-only problem when making frames invisible

[Stephen Berman]

On Sat, 04 Feb 2017 22:47:16 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> When I execute your recipe, after the make-frame-invisible invocation
>> the new frame get minimized, i.e., is only represented on the desktop as
>> an entry in the task bar (or panel in KDE terminology), and the
>> frame-visible-p invocation returns t.  Is that expected?
>
> No.  The frame should disappear from the taskbar:
>
>      On graphical displays, invisible frames are not updated and are
>      usually not displayed at all, even in a window system’s "taskbar".

I must have misinterpreted what I saw, because now after
make-frame-invisible the new frame does indeed vanish, also from the
taskbar.  Sorry for the confusion, I don't know how I thought it was
different before.  However, frame-visible-p still returns t (not
`icon').

> Can you try with an earlier version?  

I don't have an earlier build from master than from 2017-01-25, which
behaves the same.  However, with my build from emacs-25 from 2016-11-16,
frame-visible-p returns nil.

>                                       And is there any difference if, as
> a second step, you do (iconify-frame frame) instead?

This does minimize the frame to the taskbar, and frame-visible-p returns
`icon' instead of t.

Steve Berman

Re: A GTK-only problem when making frames invisible

[martin rudalics]

 > However, frame-visible-p still returns t (not
 > `icon').

So we have at least two different behaviors though I'm unsure how yours
may happen.  Here I trapped it as follows: Making the frame invisible
via x_make_frame_invisible does

   /* We can't distinguish this from iconification
      just by the event that we get from the server.
      So we can't win using the usual strategy of letting
      FRAME_SAMPLE_VISIBILITY set this.  So do it by hand,
      and synchronize with the server to make sure we agree.  */
   SET_FRAME_VISIBLE (f, 0);
   SET_FRAME_ICONIFIED (f, false);

   x_sync (f);

so f->visible is zero from now on and f->iconified is false.  Next I get
an Expose event (which is a mystery to me because why should making a
frame invisible expose it) causing the execution of

           if (!FRAME_VISIBLE_P (f))
             {
               block_input ();
               SET_FRAME_VISIBLE (f, 1);
               SET_FRAME_ICONIFIED (f, false);

because "expose events must be treated like map events" as ISTR having
read somewhere.  Hence, f->visible is one from now on and f->iconified
still false.  Finally, I get the UnmapNotify event which does

	  bool visible = FRAME_VISIBLE_P (f);
           /* While a frame is unmapped, display generation is
              disabled; you don't want to spend time updating a
              display that won't ever be seen.  */
           SET_FRAME_VISIBLE (f, 0);
           /* We can't distinguish, from the event, whether the window
              has become iconified or invisible.  So assume, if it
              was previously visible, than now it is iconified.
              But x_make_frame_invisible clears both
              the visible flag and the iconified flag;
              and that way, we know the window is not iconified now.  */
           if (visible || FRAME_ICONIFIED_P (f))
             {
               SET_FRAME_ICONIFIED (f, true);
               inev.ie.kind = ICONIFY_EVENT;
               XSETFRAME (inev.ie.frame_or_window, f);

so while f->visible is zero ,`visible' is true and SET_FRAME_ICONIFIED
will succeed in setting f->iconified to true.

 > I don't have an earlier build from master than from 2017-01-25, which
 > behaves the same.  However, with my build from emacs-25 from 2016-11-16,
 > frame-visible-p returns nil.

Same here.

 >>                                        And is there any difference if, as
 >> a second step, you do (iconify-frame frame) instead?
 >
 > This does minimize the frame to the taskbar, and frame-visible-p returns
 > `icon' instead of t.

As expected.

Thank your very much for testing.  Anyone else's experiences with this
would be highly interesting.  Something is fishy here.

martin