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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 12 Aug 2020 19:50:32 +0300

> From: Tino Calancha <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked],
>   [email-masked],  [email-masked], [email-masked]
> 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.