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

Previous Next

Package: emacs;

Reported by: "koaaa.outlook" <whainte <at> outlook.com>

Date: Tue, 7 Jun 2022 20:25:02 UTC

Severity: normal

Tags: patch

Merged with 56833, 58424

Found in version 29.0.50

Done: Po Lu <luangruo <at> yahoo.com>

Bug is archived. No further changes may be made.

Full log


Message #13 received at 55836 <at> debbugs.gnu.org (full text, mbox):

From: whainte <at> outlook.com
To: Po Lu <luangruo <at> yahoo.com>
Cc: 55836 <at> debbugs.gnu.org
Subject: Re: bug#55836: 29.0.50; (iconify-frame) freezes buffer view under
 Wayland.
Date: Mon, 20 Jun 2022 00:09:37 +0200
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.





This bug report was last modified 2 years and 192 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.