bug#67654: 29.1; Hiding menu bar makes new frames very small

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Roshan Shariff]

This bug appears on Linux with the Xorg and Xwayland servers, and I've
tested it on Gnome 45.  To reproduce

$ emacs -Q --eval='(menu-bar-mode -1)'
Invoke make-frame-command (C-x 5 2)

The initial frame is correctly sized, but any new frames are very small.
The frame-parameter function reports their size to be 22x10.  Evaluating
(set-frame-size nil 80 40) in the newly created frame does resize it
correctly, and adding that code to after-make-frame-functions works
around this bug.  Re-enabling the menu bar also makes new frames
correctly sized.

The same problem happens in daemon mode.  If the menu bar is disabled
with emacsclient -e '(menu-bar-mode -1)' immediately after starting the
daemon, the first frame created via emacsclient -c is correctly sized
but all subsequent frames are tiny.

I was able to find similar reports on the Emacs StackExchange site:
https://emacs.stackexchange.com/questions/77667/emacs-starts-in-extremely-tiny-window


In GNU Emacs 29.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.8) of 2023-09-24 built on
 e1d0f5fdfea948b9bb25e212c9c623e4
Windowing system distributor 'The X.Org Foundation', version 11.0.12302002
System Description: Fedora Linux 39 (Workstation Edition)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xpm --with-x-toolkit=gtk3 --with-gpm=no
 --with-xwidgets --with-modules --with-harfbuzz --with-cairo --with-json
 --with-native-compilation=aot --with-tree-sitter --with-sqlite3
 --with-webp --with-xinput2 build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
 -pipe -Wall -Werror=format-security
 -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig CXX=g++
 'CXXFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g
 -grecord-gcc-switches -pipe -Wall -Werror=format-security
 -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS
GTK3 ZLIB

Important settings:
  value of $LANG: en_CA.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  server-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils pp cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib server rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 79320 11837)
 (symbols 48 7249 0)
 (strings 32 19886 1256)
 (string-bytes 1 606876)
 (vectors 16 16445)
 (vector-slots 8 338535 20511)
 (floats 8 50 37)
 (intervals 56 331 0)
 (buffers 984 12))

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Roshan Shariff]

I found that this bug occurs regardless of menu-bar-mode when I'm
running without 2x desktop scaling, tested at 1920x1080 or 3840x2160
screen resolutions. In those cases, all newly created frames are tiny
regardless of whether menu-bar-mode is enabled or not.

The correlation with menu-bar-mode happens only when running at 2x
scaling with 3840x2160 resolution.

I was also able to reproduce this bug in a freshly installed Fedora 39
virtual machine, with emacs 29.1 from the distribution repository. I
also noted that the emacs-lucid build doesn't suffer from this issue,
only the GTK build.

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Roshan Shariff <roshan.shariff@gmail.com> writes:

> I found that this bug occurs regardless of menu-bar-mode when I'm
> running without 2x desktop scaling, tested at 1920x1080 or 3840x2160
> screen resolutions. In those cases, all newly created frames are tiny
> regardless of whether menu-bar-mode is enabled or not.
>
> The correlation with menu-bar-mode happens only when running at 2x
> scaling with 3840x2160 resolution.
>
> I was also able to reproduce this bug in a freshly installed Fedora 39
> virtual machine, with emacs 29.1 from the distribution repository. I
> also noted that the emacs-lucid build doesn't suffer from this issue,
> only the GTK build.

Yes, I'm aware of this problem.  But I've never successfully reproduced
it myself, and the GTK build is not important to me, so my
recommendation is to use some other build, preferably the no toolkit
one.

Let's leave this bug open for now, on the off chance a good Samaritan
devises a fix.

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Eli Zaretskii]

> Cc: 67654@debbugs.gnu.org
> Date: Wed, 06 Dec 2023 20:33:59 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Roshan Shariff <roshan.shariff@gmail.com> writes:
> 
> > I found that this bug occurs regardless of menu-bar-mode when I'm
> > running without 2x desktop scaling, tested at 1920x1080 or 3840x2160
> > screen resolutions. In those cases, all newly created frames are tiny
> > regardless of whether menu-bar-mode is enabled or not.
> >
> > The correlation with menu-bar-mode happens only when running at 2x
> > scaling with 3840x2160 resolution.
> >
> > I was also able to reproduce this bug in a freshly installed Fedora 39
> > virtual machine, with emacs 29.1 from the distribution repository. I
> > also noted that the emacs-lucid build doesn't suffer from this issue,
> > only the GTK build.
> 
> Yes, I'm aware of this problem.  But I've never successfully reproduced
> it myself, and the GTK build is not important to me, so my
> recommendation is to use some other build, preferably the no toolkit
> one.
> 
> Let's leave this bug open for now, on the off chance a good Samaritan
> devises a fix.

Did this problem exist in Emacs 28?  If not, we should at least try
understanding what changes triggered it in Emacs 29.

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Roshan Shariff]

On Wed, 6 Dec 2023 at 05:39, Eli Zaretskii <eliz@gnu.org> wrote:
> Did this problem exist in Emacs 28?  If not, we should at least try
> understanding what changes triggered it in Emacs 29.

The same problem existed on Emacs 28, but at the time I wasn't able to
narrow it down and come up with a consistent reproducer. I don't
remember if Emacs 27 had it too. When I have some time, I'll test
those older versions and see if git bisect can narrow down when the
bug appeared.

Also, I just came across bug #65559 which might be the same issue,
mentioned in https://emacs.stackexchange.com/questions/77667/emacs-starts-in-extremely-tiny-window

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Roshan Shariff]

I tried a git bisect only to find that commits as far back as ~2015
exhibit the bug; I wasn't able to compile older versions on my system
because of segfaults during compilation. So it seems plausible that
the GTK3 build of Emacs has always had this issue.

While coming up with a workaround (see below) I noticed something odd.
I added a hook to after-make-frame-functions that prints out the
frame-{char,native,text,outer}-{width,height} of the newly created
frame. I found that immediately after the frame is created, these
values are fine. But when printing them out after a brief sleep-for,
or using run-with-timer, the values actually match the size of the
tiny frame. So it seems that Emacs thinks the frame has the correct
size on creation, but learns of its actual size a little bit later.

The following workaround needs the run-with-timer (and the duration
needs to be long enough):

(add-hook 'after-make-frame-functions
   (defun +resize-after-make-frame (frame)
     ;; HACK Resize new frames shortly after creation.  Works around
     ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67654
     (when-let ((width (alist-get 'width default-frame-alist))
                (height (alist-get 'height default-frame-alist)))
       (run-with-timer (/ 1.0 60) nil #'set-frame-size frame width height))))

I figure there's little chance of finding the root cause, but
hopefully the workaround will help people who come across this.

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Roshan Shariff <roshan.shariff@gmail.com> writes:

> I tried a git bisect only to find that commits as far back as ~2015
> exhibit the bug; I wasn't able to compile older versions on my system
> because of segfaults during compilation. So it seems plausible that
> the GTK3 build of Emacs has always had this issue.

It's much more plausible that some change to GTK has introduced this
bug... so much for breaking changes not being made to GTK 3.

Every minute spent on this senseless wild goose chase at the behest of a
cabal of toolkit developers avowedly hostile to us, as they have
expressed time and again, is a minute gone to waste.  Not to say that
nobody will, but I don't see myself entering this chase.  Patches
welcome as usual, and thanks in advance.

If the no toolkit, Lucid, Motif, or GTK+ 2.x builds don't suffer this
problem, it'd be prudent to use one of those instead, and forget this
bug happened.

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  67654@debbugs.gnu.org
> Date: Mon, 11 Dec 2023 15:37:49 +0800
> 
> Roshan Shariff <roshan.shariff@gmail.com> writes:
> 
> > I tried a git bisect only to find that commits as far back as ~2015
> > exhibit the bug; I wasn't able to compile older versions on my system
> > because of segfaults during compilation. So it seems plausible that
> > the GTK3 build of Emacs has always had this issue.
> 
> It's much more plausible that some change to GTK has introduced this
> bug... so much for breaking changes not being made to GTK 3.

Sounds like some GTK setting gets in the way and changes the
dimensions?

If the OP wanted to look deeper into this problem, would it be
possible to provide instructions where to look and which variables or
events to examine?

bug#67654: 29.1; Hiding menu bar makes new frames very small

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Sounds like some GTK setting gets in the way and changes the
> dimensions?
>
> If the OP wanted to look deeper into this problem, would it be
> possible to provide instructions where to look and which variables or
> events to examine?

I'm not certain.  I would suggest downgrading GTK in increments, and
searching through its ChangeLog for each release between the first to
function correctly and the one installed for possibly related changes.

Since we've never received these reports before roughly the release of
Emacs 29.1, there shouldn't be too many versions to work through.  It's
allegedly in "maintainence mode" after all.

bug#67654: 29.1; Hiding menu bar makes new frames very small

[John Avery]

On 12/11/23 02:13, Roshan Shariff wrote:
> I tried a git bisect only to find that commits as far back as ~2015
> exhibit the bug; I wasn't able to compile older versions on my system
> because of segfaults during compilation. So it seems plausible that
> the GTK3 build of Emacs has always had this issue.
> 
> While coming up with a workaround (see below) I noticed something odd.
> I added a hook to after-make-frame-functions that prints out the
> frame-{char,native,text,outer}-{width,height} of the newly created
> frame. I found that immediately after the frame is created, these
> values are fine. But when printing them out after a brief sleep-for,
> or using run-with-timer, the values actually match the size of the
> tiny frame. So it seems that Emacs thinks the frame has the correct
> size on creation, but learns of its actual size a little bit later.
> 
> The following workaround needs the run-with-timer (and the duration
> needs to be long enough):
> 
> (add-hook 'after-make-frame-functions
>     (defun +resize-after-make-frame (frame)
>       ;; HACK Resize new frames shortly after creation.  Works around
>       ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67654
>       (when-let ((width (alist-get 'width default-frame-alist))
>                  (height (alist-get 'height default-frame-alist)))
>         (run-with-timer (/ 1.0 60) nil #'set-frame-size frame width height))))
> 
> I figure there's little chance of finding the root cause, but
> hopefully the workaround will help people who come across this.
> 

I have only seen the problem since moving to Ubuntu 24.04 (with Gnu 
Emacs 29.3).  Previously I was running Ubuntu 23.10 with its default Emacs.

Before seeing any bug reports I came up with an after make frame 
function.  It now incorporates most of your code and also takes 
advantage of your observation about 
frame-{char,native,text,outer}-{width,height} of the newly created 
frame.  Thank you!

I have not tested it extensively, but it has worked without fail for 
nearly two weeks.

(add-hook 'after-make-frame-functions
    (defun +resize-after-make-frame (frame)
      "HACK Resize new frames shortly after creation.  Works around 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67654"
      (let ((width (/ (frame-text-width frame) (frame-char-width frame)))
            (height (/ (frame-text-height frame) (frame-char-height 
frame))))
        (sleep-for 0 1)
        (set-frame-size frame width height))))