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