bug#64923: 29.1; white background glitch with new graphical frames

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Thiago Melo <tmdmelo@gmail.com> writes:

> Under the conditions specified below, new graphical frames are
> completely white until a redrawing is forced (usually by resizing the
> frame):
>
> Emacs built with:
>
> - No toolkit OR Lucid (--with-x-toolkit=no OR --with-x-toolkit=lucid)
> - Cairo (--with-cairo)
> - Double buffering (--with-xdbe)
>
> Plus:
>
> - Without an X window manager OR using TinyWM
> - No toolkit builds: when scrollbar is disabled before creating the frame
> - Lucid builds: when scrollbar AND menubar are disabled before
> creating the frame
>
> Affects `emacs -Q'.  Tested on Debian GNU/Linux 12.1 (Bookworm).
>
> Issue started happening since commit
> e361d0d7e5d3db8575d5d8673012aa4d7448ee54 (Tue Mar 1 20:15:02 2022
> +0800, "Add PropertyChangeMask to the standard event set").  Found via
> bisect.

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?

diff --git a/src/xterm.c b/src/xterm.c
index 61b9d972e57..466b86fe32a 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -19396,6 +19396,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 
       f = x_top_window_to_frame (dpyinfo, event->xproperty.window);
       if (f && event->xproperty.atom == dpyinfo->Xatom_net_wm_state
+	  && 0
 	  /* This should never happen with embedded windows.  */
 	  && !FRAME_X_EMBEDDED_P (f))
 	{
@@ -19441,6 +19442,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 	}
 
       if (f && event->xproperty.atom == dpyinfo->Xatom_wm_state
+	  && 0
 	  && !FRAME_X_EMBEDDED_P (f) && !FRAME_PARENT_FRAME (f))
 	/* Handle WM_STATE.  We use this to clear the iconified flag
 	   on a frame if it is set.