bug#42655: 27.1; iconify-frame on a Lucid build may stuck the frame

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: 42655@debbugs.gnu.org,  eggert@cs.ucla.edu,  uyennhi.qm@gmail.com,
>   bhavin7392@gmail.com,  monnier@iro.umontreal.ca, dancol@dancol.org
> Date: Mon, 10 Aug 2020 19:52:39 +0200
> 
> > I see in xterm.c that we already have some special treatment of the
> > Gnome Shell, see below.  Could you please put a breakpoint there, and
> > tell why we don't set the frame's visible flag and don't reset its
> > iconified flag when the PropertyNotify event is received?  Your event
> > log seems to indicate we get quite a few of PropertyNotify events when
> > the frame is de-iconified.
> That break point is only reached while creating the frame or clicking
> the menu bars.  Once the frame is created, I am not able to reach that
> part by minimize/unminimize.
> 
> I have printed out `event->type` right before the switch(event->type)
> I enter the break point at PropertyNotify when `event->type` equals 28.
> The xev utility is printing out PropertyNotify for a bunch of different
> values of `event->type`, not just for 28.
> 
> 
> Naively, I can workaround this issue by checking for an iconified frame at
> FocusIn:  this fixes this issue in both `emacs -Q` and my
> custom Emacs session.

That would be my next idea, so please go ahead and install this.  And
thanks for all the footwork in investigating this issue.

> +      /* Some WMs (e.g. Mutter in Gnome Shell), don't unmap 
> minimized/iconified windows;
> +         thus, for those WMs we won't get a MapNotify when 
> unminimizing/deconifying.
> +         Check here if we are deconizing a window (Bug42655). */

Please M-q in this comment, to make its lines shorter.