bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

> We can reproduce the issue in our machine [1].
> The following patch works for us:
>
> commit 3f4aec4692b2e87bf69856b6d5870be46fd61f1e
>      Fix Bug#55836
>
>      * src/pgtkterm.c (window_state_event):
>      Always set the frame visible when deiconifying it (Bug#55836).
>
> diff --git a/src/pgtkterm.c b/src/pgtkterm.c
> index 491ba33882..4a62ca0e41 100644
> --- a/src/pgtkterm.c
> +++ b/src/pgtkterm.c
> @@ -5508,6 +5508,7 @@ window_state_event (GtkWidget *widget,
>         inev.ie.kind = DEICONIFY_EVENT;
>         XSETFRAME (inev.ie.frame_or_window, f);
>         SET_FRAME_ICONIFIED (f, false);
>
> +      SET_FRAME_VISIBLE (f, 1); /* Bug#55836 */
>       }
>
>     if (new_state & GDK_WINDOW_STATE_STICKY)

Is that on Wayland or X?

Note that the PGTK build does not support X anyway, but please try this:

diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 491ba33882..cb4351616e 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -6424,10 +6424,12 @@ pgtk_set_event_handler (struct frame *f)
 			G_CALLBACK (pgtk_handle_event), NULL);
       g_signal_connect (G_OBJECT (FRAME_GTK_OUTER_WIDGET (f)), "configure-event",
 			G_CALLBACK (configure_event), NULL);
+
+      /* The map event always comes from the toplevel window.  */
+      g_signal_connect (G_OBJECT (FRAME_GTK_OUTER_WIDGET (f)), "map-event",
+			G_CALLBACK (map_event), NULL);
     }
 
-  g_signal_connect (G_OBJECT (FRAME_GTK_WIDGET (f)), "map-event",
-		    G_CALLBACK (map_event), NULL);
   g_signal_connect (G_OBJECT (FRAME_GTK_WIDGET (f)), "size-allocate",
 		    G_CALLBACK (size_allocate), f);
   g_signal_connect (G_OBJECT (FRAME_GTK_WIDGET (f)), "key-press-event",

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

> Your patch fixes the issue as well.

It'd be interesting to see why GDK sends map events in that case.

Before I install that change, I'd like to ask you what Wayland
compositor you are using, and how you deiconified the frame.

Thanks.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

> I am sorry, I was running on X11:

Yes, that's what I expected.

> $ inxi -Gxx | grep compositor
> Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver: loaded: qxl
>
> I have restarted the session, now on Wayland:
> $ inxi -Gxx | grep compositor
>   compositor: kwin_wayland driver: loaded: qxl
>
> Under Wayland:
> - My patch fixes the issue.
> - Your patch doesn't fix it.

What if you use GNOME Shell?  The problem is no window state changes are
normally sent by GDK under Wayland, so Emacs doesn't even get to the
piece of code that clears FRAME_ICONIFIED_P.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

>> What if you use GNOME Shell?  The problem is no window state changes are
>> normally sent by GDK under Wayland, so Emacs doesn't even get to the
>> piece of code that clears FRAME_ICONIFIED_P.
>
> Under Gnome Shell both patches fix the issue in my machine.

That's really odd.  But I think I now know what's going on.

Could you install debug info for GDK, put breakpoints on both
window_state_event (in pgtkterm.c) and
gdk_wayland_window_handle_configure (in gdkwindow-wayland.c)?

Please see whether the former is called after the latter, and in doing
so clears the iconified flag?

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Tino Calancha]

On Tue, 27 Sep 2022, Po Lu wrote:

> Could you install debug info for GDK, put breakpoints on both
> window_state_event (in pgtkterm.c) and
> gdk_wayland_window_handle_configure (in gdkwindow-wayland.c)?

I don't know how to set the second breakpoint :-|

This is what I have done:

1. Installed packages gtk3-debugsource, gtk3-devel-debuginfo, libgtk-3-0-debuginfo

After that, I can see the file at:
/usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c

2.
M-x: gdb RET

(gdb) b pgtkterm.c:5458
Breakpoint 2 at 0x752a69: file pgtkterm.c, line 5458.
(gdb) b /usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c:1657
No source file named /usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c.
Breakpoint 3 (/usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c:1657) pending.
(gdb)

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

> On Tue, 27 Sep 2022, Po Lu wrote:
>
>> Could you install debug info for GDK, put breakpoints on both
>> window_state_event (in pgtkterm.c) and
>> gdk_wayland_window_handle_configure (in gdkwindow-wayland.c)?
>
> I don't know how to set the second breakpoint :-|
>
> This is what I have done:
>
> 1. Installed packages gtk3-debugsource, gtk3-devel-debuginfo, libgtk-3-0-debuginfo
>
> After that, I can see the file at:
> /usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c
>
> 2.
> M-x: gdb RET
>
> (gdb) b pgtkterm.c:5458
> Breakpoint 2 at 0x752a69: file pgtkterm.c, line 5458.
> (gdb) b /usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c:1657
> No source file named /usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c.
> Breakpoint 3 (/usr/src/debug/gtk3-3.24.31-150400.1.11.x86_64/gdk/wayland/gdkwindow-wayland.c:1657) pending.
> (gdb)

You should simply be able to type "b gdk_wayland_window_handle_configure".

Thanks in advance.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Tino Calancha]

On Thu, 29 Sep 2022, Po Lu wrote:

> You should simply be able to type "b gdk_wayland_window_handle_configure".

I see, thank you.

> Could you install debug info for GDK, put breakpoints on both
> window_state_event (in pgtkterm.c) and
> gdk_wayland_window_handle_configure (in gdkwindow-wayland.c)?

> Please see whether the former is called after the latter, and in doing
> so clears the iconified flag?

This is what I see:

1. The breakpoint at gdk_wayland_window_handle_configure is never reached.
    I have tried with both patches discussed above, and the master branch
    with no success: such breakpoint is not reached.

2. I have played with the following patch that also fixes the issue in my
    machine:

--8<-----------------------------cut here---------------start------------->8---
diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 491ba33..58456c9 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -5502,13 +5502,6 @@ window_state_event (GtkWidget *widget,

    if (new_state & GDK_WINDOW_STATE_ICONIFIED)
      SET_FRAME_ICONIFIED (f, true);
-  else
-    {
-      FRAME_X_OUTPUT (f)->has_been_visible = true;
-      inev.ie.kind = DEICONIFY_EVENT;
-      XSETFRAME (inev.ie.frame_or_window, f);
-      SET_FRAME_ICONIFIED (f, false);
-    }

    if (new_state & GDK_WINDOW_STATE_STICKY)
      store_frame_param (f, Qsticky, Qt);
--8<-----------------------------cut here---------------end--------------->8---

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

> On Thu, 29 Sep 2022, Po Lu wrote:
>
>> You should simply be able to type "b gdk_wayland_window_handle_configure".
>
> I see, thank you.
>
>> Could you install debug info for GDK, put breakpoints on both
>> window_state_event (in pgtkterm.c) and
>> gdk_wayland_window_handle_configure (in gdkwindow-wayland.c)?
>
>> Please see whether the former is called after the latter, and in doing
>> so clears the iconified flag?
>
> This is what I see:
>
> 1. The breakpoint at gdk_wayland_window_handle_configure is never reached.
>     I have tried with both patches discussed above, and the master branch
>     with no success: such breakpoint is not reached.
>
> 2. I have played with the following patch that also fixes the issue in my
>     machine:
>
> diff --git a/src/pgtkterm.c b/src/pgtkterm.c
> index 491ba33..58456c9 100644
> --- a/src/pgtkterm.c
> +++ b/src/pgtkterm.c
> @@ -5502,13 +5502,6 @@ window_state_event (GtkWidget *widget,
>
>     if (new_state & GDK_WINDOW_STATE_ICONIFIED)
>       SET_FRAME_ICONIFIED (f, true);
> -  else
> -    {
> -      FRAME_X_OUTPUT (f)->has_been_visible = true;
> -      inev.ie.kind = DEICONIFY_EVENT;
> -      XSETFRAME (inev.ie.frame_or_window, f);
> -      SET_FRAME_ICONIFIED (f, false);
> -    }
>
>     if (new_state & GDK_WINDOW_STATE_STICKY)
>       store_frame_param (f, Qsticky, Qt);

That's shocking.  I will look into this further myself (in a Wayland
session.)

Thanks.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Tino Calancha]

On Fri, 30 Sep 2022, Po Lu wrote:

>> 1. The breakpoint at gdk_wayland_window_handle_configure is never reached.
>>     I have tried with both patches discussed above, and the master branch
>>     with no success: such breakpoint is not reached.

It turned out I was missing some debugging symbols.
Once iinstalled all the debugging symbols the breakpoint is reached as 
expected.


>>> Could you install debug info for GDK, put breakpoints on both
>>> window_state_event (in pgtkterm.c) and
>>> gdk_wayland_window_handle_configure (in gdkwindow-wayland.c)?
>>
>>> Please see whether the former is called after the latter, and in doing
>>> so clears the iconified flag?

The iconified flag is cleared, but I cannot tell you where this happens.
Of course, that prevents us to enter in the `if` branch at line 5472:
if (FRAME_ICONIFIED_P (f))


My two fixes point to the `else` branch at line 5505:

```
   if (new_state & GDK_WINDOW_STATE_ICONIFIED)
     SET_FRAME_ICONIFIED (f, true);
   else
     {
       FRAME_X_OUTPUT (f)->has_been_visible = true;
       inev.ie.kind = DEICONIFY_EVENT;
       XSETFRAME (inev.ie.frame_or_window, f);
       SET_FRAME_ICONIFIED (f, false);
     }
```

1. The first one "extends" this branch by adding this line:

SET_FRAME_VISIBLE (f, 1);

2. The second one just removes that `else` branch.

Both seems to fix the issue in my Wayland session.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

> Both seems to fix the issue in my Wayland session.

Thanks.

I decided to take another look at this today.  What GDK does is a hack
that works for some people: after a window is iconified, it sends a
configure event containing the iconified state to the program.  Upon the
next xdg_toplevel.configure event, it assumes the window has been
deiconified.

That is wrong!  In many situations, it is valid for the compositor to
send yet another toplevel configure event.  For example, the pager
component of the compositor may want the program to resize its toplevel
before it displays a preview of said toplevel to the user.

It is also valid for the compositor to deiconify a frame without
focusing it, or changing any state at all (which would entail sending a
configure event.)

However, with something similar the second change, it seems to work for
at least half of our users, which is better than having iconification
work for nobody at all.  So would you be so kind as to check if the bug
is now fixed on master?

(It may take some time for me to push: savannah seems to be having
problems ATM.)

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Tino Calancha]

On Wed, 9 Nov 2022, Po Lu wrote:

> However, with something similar the second change, it seems to work for
> at least half of our users, which is better than having iconification
> work for nobody at all.  So would you be so kind as to check if the bug
> is now fixed on master?

Your patch fixes the issue in my test machine [1].
Thank you!


[1]

In GNU Emacs 29.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
  3.24.34, cairo version 1.17.6) of 2022-11-10 built on
  localhost.localdomain
Repository revision: f8df45f853752bb842af453dd05ccb64d990b767
Repository branch: master
System Description: openSUSE Tumbleweed

Configured using:
  'configure --with-pgtk --enable-checking=yes,glyphs
  --enable-check-lisp-object-type 'CFLAGS=-O0 -g3'
  --with-gnutls=ifavailable'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GSETTINGS HARFBUZZ JPEG LIBSELINUX MODULES
NOTIFY INOTIFY PDUMPER PGTK PNG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tino Calancha <tino.calancha@gmail.com> writes:

> On Wed, 9 Nov 2022, Po Lu wrote:
>
>> However, with something similar the second change, it seems to work for
>> at least half of our users, which is better than having iconification
>> work for nobody at all.  So would you be so kind as to check if the bug
>> is now fixed on master?
>
> Your patch fixes the issue in my test machine [1].
> Thank you!

Thanks.  I'm closing this bug then.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[koaaa.outlook]

* (iconify-frame) freezes buffer view under Wayland.  *
This issue is not present under X11 sessions.

Steps to reproduce:
1. Run 'emacs -Q' within a (e.g. KDE Plasma) Wayland session.
2. Input 'M-x iconify-frame C-m'.
3. Maximize emacs again.

Expected Behavior: Buffer area keeps on updating itself.

Observed Behavior: Buffer area freezes at the moment where
'C-m' is put in. The menu bar updates as normal.
Emacs responds to user input without redrawing the buffer area.

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.34, cairo version 1.17.6)
of 2022-06-06 built on soomakan
Repository revision: dc9337aacd682b6346b7918ec9b3067e3a06269b
Repository branch: master
System Description: Arch Linux

Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
--with-modules --without-libotf --without-m17n-flt --without-gconf
--enable-autodepend --with-native-compilation --with-xinput2
--with-pgtk --without-xaw3d --with-sound=alsa
--without-compress-install --with-json
'--program-transform-name=s/\([ec]tags\)/\1.emacs/'
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -g
-ffile-prefix-map=/home/koaaa/.cache/yay/emacs-git/src=/usr/src/debug'
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP XIM GTK3 ZLIB

Important settings:
value of $LC_MONETARY: C
value of $LC_NUMERIC: C
value of $LC_TIME: C
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=fcitx
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 57609 7544)
(symbols 48 5706 0)
(strings 32 16226 1785)
(string-bytes 1 542740)
(vectors 16 12655)
(vector-slots 8 278543 13041)
(floats 8 21 25)
(intervals 56 247 0)
(buffers 992 10))

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"koaaa.outlook" <whainte@outlook.com> writes:

> * (iconify-frame) freezes buffer view under Wayland.  *
> This issue is not present under X11 sessions.
>
> Steps to reproduce:
> 1. Run 'emacs -Q' within a (e.g. KDE Plasma) Wayland session.
> 2. Input 'M-x iconify-frame C-m'.
> 3. Maximize emacs again.
>
> Expected Behavior: Buffer area keeps on updating itself.
>
> Observed Behavior: Buffer area freezes at the moment where
> 'C-m' is put in. The menu bar updates as normal.
> Emacs responds to user input without redrawing the buffer area.
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.34, cairo version 1.17.6)
> of 2022-06-06 built on soomakan
> Repository revision: dc9337aacd682b6346b7918ec9b3067e3a06269b
> Repository branch: master
> System Description: Arch Linux

I think this is a GTK bug, where the developers neglected to maintain
the iconification state on Wayland after GNOME removed the minimize
button from window title bars.

Can you set a breakpoint here (in pgtkterm.c), and see if it is ever hit
when you deiconify Emacs?

  if (event->window_state.new_window_state
      & GDK_WINDOW_STATE_ICONIFIED)
    SET_FRAME_ICONIFIED (f, true);
  else
    {
-->   FRAME_X_OUTPUT (f)->has_been_visible = true;
      inev.ie.kind = DEICONIFY_EVENT;
      XSETFRAME (inev.ie.frame_or_window, f);
      SET_FRAME_ICONIFIED (f, false);
    }

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[whainte]

On 6/8/22 02:32, Po Lu wrote:

> Can you set a breakpoint here (in pgtkterm.c), and see if it is ever hit
> when you deiconify Emacs?
>
>    if (event->window_state.new_window_state
>        & GDK_WINDOW_STATE_ICONIFIED)
>      SET_FRAME_ICONIFIED (f, true);
>    else
>      {
> -->   FRAME_X_OUTPUT (f)->has_been_visible = true;
>        inev.ie.kind = DEICONIFY_EVENT;
>        XSETFRAME (inev.ie.frame_or_window, f);
>        SET_FRAME_ICONIFIED (f, false);
>      }
>
This breakpoint actually hits whenever the emacs frame gets focus, and 
makes debugging quite annoying.
However, by inputting M-x + <tab> during the breakpoint and using the 
mouse when the frame does not
have focus, it is possible to execute (iconify-frame) interactively 
after triggering the breakpoint.

Here's the strange thing: when a breakpoint is set there, the issue is 
not present; when the breakpoint
is deleted and the procedure repeated, the issue reappears.

I would conjecture that this has to do with the state of the frame at 
the moment of (de-)/iconification,
since when the breakpoint IS present, I would have to be looking at gdb, 
cycling through 'continue's.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

whainte@outlook.com writes:

>>    if (event->window_state.new_window_state
>>        & GDK_WINDOW_STATE_ICONIFIED)
>>      SET_FRAME_ICONIFIED (f, true);
>>    else
>>      {
>> -->   FRAME_X_OUTPUT (f)->has_been_visible = true;
>>        inev.ie.kind = DEICONIFY_EVENT;
>>        XSETFRAME (inev.ie.frame_or_window, f);
>>        SET_FRAME_ICONIFIED (f, false);
>>      }
>>
> This breakpoint actually hits whenever the emacs frame gets focus, and
> makes debugging quite annoying.
> However, by inputting M-x + <tab> during the breakpoint and using the
> mouse when the frame does not
> have focus, it is possible to execute (iconify-frame) interactively
> after triggering the breakpoint.
>
> Here's the strange thing: when a breakpoint is set there, the issue is
> not present; when the breakpoint
> is deleted and the procedure repeated, the issue reappears.
>
> I would conjecture that this has to do with the state of the frame at
> the moment of (de-)/iconification,
> since when the breakpoint IS present, I would have to be looking at
> gdb, cycling through 'continue's.

I didn't understand what you said, but I guess you should make the
breakpoint conditional on "FRAME_ICONIFIED_P (f)".

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> This breakpoint actually hits whenever the emacs frame gets focus, and
>> makes debugging quite annoying.
>> However, by inputting M-x + <tab> during the breakpoint and using the
>> mouse when the frame does not
>> have focus, it is possible to execute (iconify-frame) interactively
>> after triggering the breakpoint.
>>
>> Here's the strange thing: when a breakpoint is set there, the issue is
>> not present; when the breakpoint
>> is deleted and the procedure repeated, the issue reappears.
>>
>> I would conjecture that this has to do with the state of the frame at
>> the moment of (de-)/iconification,
>> since when the breakpoint IS present, I would have to be looking at
>> gdb, cycling through 'continue's.
>
> I didn't understand what you said, but I guess you should make the
> breakpoint conditional on "FRAME_ICONIFIED_P (f)".

I didn't quite understand the text here, either.  whainte, are you still
seeing this problem, and if so, can you try Po's suggestion?

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[夜坂雅 via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I have tried to reproduce this but failed.

> Po Lu <luangruo@yahoo.com> writes:
>
>>> This breakpoint actually hits whenever the emacs frame gets focus, and
>>> makes debugging quite annoying.

Yes.

>>> Here's the strange thing: when a breakpoint is set there, the issue is
>>> not present; when the breakpoint
>>> is deleted and the procedure repeated, the issue reappears.

I tried:
1. In GDB, setup the breakpoint.
2. When the emacs got focus, switch to GDB prompt and run `continue'.
3. Switch back to the Emacs window, it should now stuck. Hit C-z, then
switch to GDB prompt and run `continue'.
4. Emacs should iconify itself. Deiconify it. It'll hit breakpoint
again. switch to GDB prompt and run `continue'.
5. Select Help in the menu bar. It'll hit breakpoint. switch to GDB
prompt and run `continue'.
6. The menu should pop up. run the Emacs tutorial.
7. Scroll in the Emacs window.

The Emacs tutorial can be scrolled.
However when I disable the breakpoint, When I deiconified the Emacs
window, it doesn't update even I tried to launch Emacs tutorial.

>> I didn't understand what you said, but I guess you should make the
>> breakpoint conditional on "FRAME_ICONIFIED_P (f)".

I tried, but GDB failed to setup this condition with:
No symbol "FRAME_ICONIFIED_P" in current context.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

夜坂雅 <shadowrz@disroot.org> writes:

> I tried, but GDB failed to setup this condition with:
> No symbol "FRAME_ICONIFIED_P" in current context.

Hmm, okay, how about "f->iconified == true"?

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[夜坂雅 via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Hmm, okay, how about "f->iconified == true"?

I can setup a condition of f->iconified.

So:

1. Setup GDB to break at the location you said, which (I believe) is src/pgtkterm.c:5507
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/pgtkterm.c#n5507
2. Setup a condition of f->iconified on the breakpoint.
3. Start Emacs PGTK and iconify it. It'll hit breakpoint. run `continue'
in GDB.
4. Deiconify it. This breakpoint won't be hit.

Feel free to ask me to provide more infomation.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

夜坂雅 <shadowrz@disroot.org> writes:

> I can setup a condition of f->iconified.
>
> So:
>
> 1. Setup GDB to break at the location you said, which (I believe) is src/pgtkterm.c:5507
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/pgtkterm.c#n5507
> 2. Setup a condition of f->iconified on the breakpoint.
> 3. Start Emacs PGTK and iconify it. It'll hit breakpoint. run `continue'
> in GDB.
> 4. Deiconify it. This breakpoint won't be hit.
>
> Feel free to ask me to provide more infomation.

Does the bug still happen with this patch applied?  It does mean that
iconification will no longer be reported correctly, but GDK simply
doesn't report iconification state to programs on Wayland.

diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index b283cef7cd..68365c0887 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -734,7 +734,7 @@ pgtk_iconify_frame (struct frame *f)
 
       gtk_window_iconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));
       SET_FRAME_VISIBLE (f, 0);
-      SET_FRAME_ICONIFIED (f, true);
+      /* SET_FRAME_ICONIFIED (f, true); */
       unblock_input ();
       return;
     }

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[夜坂雅 via Bug reports for GNU Emacs, the Swiss army knife of text editors]

夜坂雅 <shadowrz@disroot.org> writes:

> Quoting Po Lu (2022-09-03 13:01:11)
>> Does the bug still happen with this patch applied?  It does mean that
>> iconification will no longer be reported correctly, but GDK simply
>> doesn't report iconification state to programs on Wayland.
>
> This bug can still happen with your patch applied.
>
> Another thing I found interesting: I also used M-x server-start so
> emacsclient can control this Emacs. Without your patch,
> When I iconify Emacs via emacsclient by running:
>
> $ emacsclient -e '(iconify-or-deiconify-frame)'
>
> I can't deiconify it using the same command. But I can deiconify it
> using the taskbar (I use Latte Dock's taskbar), and the bug doesn't
> happen.
>
> But when I apply your patch, running
>
> $ emacsclient -e '(iconify-or-deiconify-frame)'
>
> and deiconify it using taskbar, the bug happens.

Sorry, for whatever reason the mail was lost and not found in debbugs so
I have to resend it again.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

夜坂雅 <shadowrz@disroot.org> writes:

>> Another thing I found interesting: I also used M-x server-start so
>> emacsclient can control this Emacs. Without your patch,
>> When I iconify Emacs via emacsclient by running:
>>
>> $ emacsclient -e '(iconify-or-deiconify-frame)'
>>
>> I can't deiconify it using the same command. But I can deiconify it
>> using the taskbar (I use Latte Dock's taskbar), and the bug doesn't
>> happen.

That's to be expected.  It turns out that programmatically deiconifying
a window isn't supported by the Wayland protocol (see here:
https://wayland.app/protocols/xdg-shell#xdg_toplevel is missing a
function corresponding to "SetMinimized" to disable the minimized
state), so GDK and Emacs don't support it either.

>> But when I apply your patch, running
>>
>> $ emacsclient -e '(iconify-or-deiconify-frame)'
>>
>> and deiconify it using taskbar, the bug happens.

I'm not sure what you mean by that.  What happens if you comment out
every call to `SET_FRAME_ICONIFIED' in pgtkterm.c?

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[夜坂雅 via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> That's to be expected.  It turns out that programmatically deiconifying
> a window isn't supported by the Wayland protocol (see here:
> https://wayland.app/protocols/xdg-shell#xdg_toplevel is missing a
> function corresponding to "SetMinimized" to disable the minimized
> state), so GDK and Emacs don't support it either.

😅

>>> But when I apply your patch, running
>>>
>>> $ emacsclient -e '(iconify-or-deiconify-frame)'
>>>
>>> and deiconify it using taskbar, the bug happens.
>
> I'm not sure what you mean by that.

1. Apply your said patch and build Emacs.
2. Run emacs and M-x server-start.
3. Run emacsclient -e '(iconify-or-deiconify-frame)' to iconify it.
4. Deiconify it. This window won't refresh when I try to run Emacs
tutorial from the menu bar.

> What happens if you comment out every call to `SET_FRAME_ICONIFIED' in pgtkterm.c?

The bug can still happen, which means even commenting every call to
SET_FRAME_ICONIFIED, Emacs is still unable to update frame when
iconified using C-z.

bug#55836: 29.0.50; (iconify-frame) freezes buffer view under Wayland.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

夜坂雅 <shadowrz@disroot.org> writes:

> The bug can still happen, which means even commenting every call to
> SET_FRAME_ICONIFIED, Emacs is still unable to update frame when
> iconified using C-z.

I'm stumped.  Does anyone know if other code (outside *term.c) also does
SET_FRAME_ICONIFIED?  I can't find anything.

Thanks.