bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: David Fussner <dfussner@googlemail.com>
> Date: Sun, 13 Dec 2020 21:22:29 +0000
> Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> 
> I'm sorry I haven't been clear enough. The original bug -- the empty
> new frame, with only a title bar, menu bar, and scroll bar, but with
> an empty main window and no mode line or minibuffer -- still occurs
> even after clearing the kwin setting I mentioned. Kwin was responsible
> for the mistake I made in my original bisection, which showed that
> Stefan's commit (36431e1679) was the first to produce the bug. In
> fact, Stefan's commit only revealed a bug that had been produced, I
> believe, by J Scott Berg's earlier commit (2c0cd9008) which altered a
> test in xterm.c (l. 8950). That revised test, when I stepped through
> the code, fails to trigger a resize when there is no tool bar, though
> it does trigger a resize when there is a tool bar. (The old test,
> pre-2c0cd9008, triggers a resize in both situations.) For reasons that
> are still obscure to me, without that resize all text in the main
> window is invisible after the creation of the new frame, and remains
> so until I manually resize the frame. Compiling with different
> toolkits and with or without cairo drawing affects whether the bug
> appears or not, but in the default gtk3 + cairo build the bug is still
> present, even without the spurious kwin setting. As I understood the
> thread concerning bug #44002, that fix was not regarded as obviously
> safe, and was therefore reserved for master. I'm suggesting,
> therefore, that at least in my case that fix isn't safe, though it
> would appear that I'm the only user running master who has run into
> such an issue. I had hoped that someone might have an idea of how to
> fix J Scott Berg's fix so that it worked both for vcxsrv and for
> 32-bit slackware 14.2. (None of my attempts have worked).

Thanks.  Does the patch below give good results?

Martin, given what was found during investigation of bug#44002, do you
agree the below should avoid re-introducing that bug?

diff --git a/src/xterm.c b/src/xterm.c
index 3de0d2e..7f8728e 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8947,7 +8947,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       if (!f
          && (f = any)
          && configureEvent.xconfigure.window == FRAME_X_WINDOW (f)
-         && FRAME_VISIBLE_P(f))
+         && (FRAME_VISIBLE_P(f)
+             || !(configureEvent.xconfigure.width <= 1
+                  && configureEvent.xconfigure.height <= 1)))
         {
           block_input ();
           if (FRAME_X_DOUBLE_BUFFERED_P (f))
@@ -8962,7 +8964,10 @@ handle_one_xevent (struct x_display_info *dpyinfo,
           f = 0;
        }
 #endif
-      if (f && FRAME_VISIBLE_P(f))
+      if (f
+         && (FRAME_VISIBLE_P(f)
+             || !(configureEvent.xconfigure.width <= 1
+                  && configureEvent.xconfigure.height <= 1)))
        {
 #ifdef USE_GTK
          /* For GTK+ don't call x_net_wm_state for the scroll bar