[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#42655: 27.1; iconify-frame on a Lucid build may stuck the frame
Date: Wed, 12 Aug 2020 19:50:32 +0300

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]