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

[Tino Calancha <tino.calancha@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

CC Daniel whom might have some ideas.

A bit of context.
Some WMs (e.g. Mutter in Gnome Shell or Muffin) follow a new trend: they
don't unmap windows when they are iconified.
https://gitlab.gnome.org/GNOME/mutter/-/issues/185

Since they are never unmapped, the windows are not mapped back when they
are deconified.  This might cause an unresponsive frame in Lucid Emacs
builds, because we redisplay when we get the MapNotify signal
(that we don't receive in those WMs).

Apparentely, GTK3 Emacs builds are not affected by this issue.

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

I am not sure if this is a convenient way.  We might also want to make
it more specific for checking some condition.


--8<-----------------------------cut here---------------start------------->8---
commit d9b06705a045336e1ef307cdfd523a1d5cbb9e7a
Author: Tino Calancha <ccalancha@suse.com>
Date:   Mon Aug 10 19:32:17 2020 +0200

    Fix bug 42655
    
    Some WMs (e.g. mutter in Gnome Shell) don't unmap iconized windows,
    thus we won't get a MapNotify when deconifying them.
    Check if we are deconifying a window elsewhere.
    
    - src/xterm.c (handle_one_xevent):
    Check for window deconify when receiving a FocusIn signal.

diff --git a/src/xterm.c b/src/xterm.c
index 6340700cb8..de1da2d4d4 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8760,6 +8760,19 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       goto OTHER;
 
     case FocusIn:
+      /* 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). */
+      f = any;
+      if (f && FRAME_ICONIFIED_P (f))
+	{
+          SET_FRAME_VISIBLE (f, 1);
+          SET_FRAME_ICONIFIED (f, false);
+          f->output_data.x->has_been_visible = true;
+          inev.ie.kind = DEICONIFY_EVENT;
+          XSETFRAME (inev.ie.frame_or_window, f);
+        }
+
       x_detect_focus_change (dpyinfo, any, event, &inev.ie);
       goto OTHER;
 
--8<-----------------------------cut here---------------end--------------->8---
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.21, cairo version 1.16.0)
 of 2020-08-09 built on localhost.example.com
Repository revision: dcce2b57bb91d490787dffd437b61196f1029b41
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: openSUSE Tumbleweed