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

[David Fussner]

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).

On Sun, 13 Dec 2020 at 18:53, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: David Fussner <dfussner@googlemail.com>
> > Date: Sun, 13 Dec 2020 18:17:41 +0000
> > Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> >
> > Stefan's commit did _not_ cause the bug, merely uncovered it. Kwin was
> > setting a minimum frame size for frames that matched the original
> > initial frame title "emacs@system_name", so when Stefan changed that
> > to "GNU Emacs at system_name" kwin no longer resized the frame, and
> > that seems to be the root of the problem. (I haven't any idea whatever
> > where that kwin setting came from.)
> >
> > Having eliminated the kwin setting, I was able to bisect again and
> > found that 2c0cd9008 was the culprit
>
> If the original problem was due to kwin, and you solved it, then what
> additional problem remains after that, for which you looked for the
> culprit by bisection?
>
> > which was J. Scott Berg's fix
> > for bug #44002 involving the vcxsrv X server on Windows. Reverting
> > that commit fixes my issue. Stepping through the code suggests that
> > his extra test in xterm.c (l. 8950) is preventing a resize event when
> > creating a new frame on my machine when tool-bar-mode is off. With
> > that mode on, the resize event still occurs, and new frames are
> > created normally.
>
> Then what was the problem that kwin was responsible for?