GNU bug report logs - #64923
29.1; white background glitch with new graphical frames

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Thiago Melo <tmdmelo <at> gmail.com>
Cc: 64923 <at> debbugs.gnu.org
Subject: bug#64923: 29.1; white background glitch with new graphical frames
Date: Sat, 29 Jul 2023 19:18:11 +0800

Thiago Melo <tmdmelo <at> gmail.com> writes:

> On Sat, Jul 29, 2023 at 12:20 AM Po Lu <luangruo <at> yahoo.com> wrote:
>> Perhaps a change to a window property temporarily misleads Emacs into
>> believing that the frame is iconified or otherwise invisible.  Does your
>> problem remain with the following change to xterm.c?
>>
>> [...]
>
> The problem remains, unfortunately.
>
> I'm testing it against the emacs-29 branch, by the way.

That's very unusual.  Let's try ignoring PropertyNotify events
altogether: if this doesn't work, it's not a problem with Emacs's
immediate treatment of PropertyNotify events.

diff --git a/src/xterm.c b/src/xterm.c
index 61b9d972e57..0ccfc55c96f 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -19336,6 +19336,8 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       break;
 
     case PropertyNotify:
+      goto OTHER;
+
       if (x_dnd_in_progress && x_dnd_use_toplevels
 	  && dpyinfo == FRAME_DISPLAY_INFO (x_dnd_frame)
 	  && event->xproperty.atom == dpyinfo->Xatom_wm_state)

By the way, does a frame exhibiting this problem update completely
without being resized if you run:

  (redraw-display)
  (redisplay)

?

Previous Next

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