bug#72986: Disabling menu-bar-mode changes size of new frames

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

 >> Thanks.  The geometry values are consistent with what you described.
 >> This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559.  When
 >> you run Emacs from a console or under gdb can you observe whether it
 >> triggers a
 >>
 >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
 >>
 >
 > Yes, both with Emacs 29 and git master produce this message when
 > menu-bar-mode is non-nil, and the menu bar is drawn, in both window sizes
 > (the normal sized window, and the strangely small one).

But you can't see this message when building with gtk-2 I presume.

 > The one really notable difference to the above bugs is that the 29
 >> version makes a shrunk frame only after you've removed the menubar while
 >> master makes a shrunk frame immediately.  Are the GTK versions of the
 >> Emacs 29 build and the master build the same?
 >>
 >
 > Yes, they are identical: gtk 3.24.41, Ubuntu build.

This strongly hints that there was an Emacs change affecting gtk-2 _and_
gtk-3 builds in between 29 and master.  I could imagine that commit

e087c89b1e243bbd941a4a50b4bf99613e13d016

is involved but if you could try to bisect, it would be of great help.

 > Just to make sure one thing: Would setting
 >> 'frame-resize-pixelwise' to t change anything?
 >>
 >
 > So, I did (setq frame-resize-pixelwise t), then disabled menu-bar-mode (in
 > Emacs 29), then C-x 5 2 (in both Emacs 29 & git master), and the new window
 > was small, just as before. It seems therefore to make no difference.

Which should eliminate the possibility that our size hints are
responsible.  IIRC mutter is very severe when size hints are not set up
correctly.

 > Otherwise I would try to build Emacs with gtk2, lucid or motif.
 >
 >
 > I tried building Emacs git master with gtk2, and it doesn't fix the
 > problem: the second window opened is slightly smaller than before (i.e.
 > very small indeed).

This would eliminate earlier conjectures that changes from one gtk-3
version to another would be responsible.  And it would exclude
emacsgtkfixed.c as possible culprit.

 > Building with lucid does fix the problem (both with menu-bar-mode enabled,
 > and disabled).

I suppose that all these problems happen when requests travel from GTK
to mutter and back.  Basically, mutter is not obliged to fulfill any
size or position request for any top-level (non-child frame).  BTW,
could you try adding a (user-size . t) member to 'default-frame-alist'?
And could you try doing that from an 'early-init.el' file?

martin