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>]

 > It's possible to turn on debug topics in Mutter at run-time using the
 > built-in Looking Glass debugger (`lg` from "Run Command" prompt).

Thanks, you saved my day.  I should have found out about 'lg' myself but
didn't see it wherever I went.

 > Having done this, I can see the output in journalctl.
 >
 > Using xwininfo, I found that the first window is ID 0x5000148 and the
 > second window I opened is ID 0x500031c.

Just to make sure: The first window is the initial window Emacs made
with normal size and the second window the one you make via C-x 5 2 with
the menu bar still enabled and the abnormal size.  Correct?

 > Then, the logs show, grepping for the first ID:
 >
 > Oct 26 13:33:47 ecls gnome-shell[3227]: GEOMETRY: Constraining 0x5000148 in
 > move from 50,108 1328x1430 to 50,108 1328x1430
 > Oct 26 13:33:47 ecls gnome-shell[3227]: GEOMETRY: Window 0x5000148 has
 > height_inc (34) that does not evenly divide min_height - base_height (340 -
 > 116); thus >

This and all the following complaints are probably correct.  I'm aware
that our sizes hints are incorrect and with 'lg' we can hopefully fix
them now.  But IIUC mutter only complains but does not react in any
malevolent way.  What surprises me is that for the first frame there's
no "Sending synthetic configure notify" entry.  We'll have to find out
why.

 > and for the second ID:
 >
 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: Constraining 0x500031c in
 > move from 130,188 400x512 to 130,188 400x512

What surprises me most is that here we start already with a size
constrained to 400x512.  Where would that come from?  Basically, it
means whatever causes the frame to shrink must have happened before
mutter writes out the first log entry.

 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: require_titlebar_visible
 > for 0x500031c toggled to TRUE

This one is strange too.  Why on earth would we turn the title bar on
here ...

 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: Sending synthetic
 > configure notify to 0x500031c with x: 130 y: 244 w: 400 h: 374
 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: Constraining 0x500031c in
 > move from 0,58 400x430 to 0,0 400x456
 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: Setting
 > _NET_FRAME_EXTENTS on managed window 0x500031c to left = 0, right = 0, top
 > = 56, bottom = 0
 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: require_titlebar_visible
 > for 0x500031c toggled to FALSE

... and off here?

 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: Constraining 0x500031c in
 > move from 0,0 1328x1258 to 0,0 400x456

This one is the most interesting entry here: Somehow we must have got
through with our idea of a 1328x1258 frame (which should IMHO mean that
GTK could not possibly have intercepted it as with the earlier ones) but
mutter immediately constrains it back to 400x456.  I'd guess from this
that mutter _is_ responsible for the shrinking albeit in consensus with
GTK.

 > Oct 26 13:33:48 ecls gnome-shell[3227]: GEOMETRY: Window 0x500031c sets min
 > height to 0, which makes no sense

Likely another silly size hint we generate.

 > These traces include the "Sending synthetic configure" message you
 > mentioned, hopefully helpful!
 >
 > (At least good to know that it's easy to turn on debugging in a production
 > build.)

It's more.  For the first time I see a way to guess how mutter proceeds.
Can you please do the same you did above for a Lucid, Motif or a
--with-x-toolkit=no build - the one you find most convenient to build.
Maybe by comparing the logs we can understand better.

Thanks, martin