bug#74496: 30.0.91; fullscreen frame set with F11 is shifted when ctwm restarts

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

 >  From the data below, I see that a `maximized' full screen will leave a
 > gap at the bottom border.  The outer-size stays at `1914 . 1069'.  The
 > gap persists across ctwm restart.
 >
 > In the case of ctwm restart on `F11 fullscreen' the windowframe
 > outer-size parameter goes from `1920 . 1080' to `1914 . 1069'.

So we have 6 pixels width and 11 pixels height less.  Doesn't make much
sense to me.

 > Emacs 29.4 behaves the same.
 >
 > More information, CTWM's window context menu for zoom, zoom-v, zoom-h
 > does the following to an initial frame
 >
 >    outer-size frame parameter changes
 >    - 674  . 678  <= initial
 >    - 1914 . 1069    zoom
 >    - 674  . 1069    zoom-v
 >    - 1914 . 678     zoom-h

But this implies that zooming does _not_ do what you want (at least not
entirely) and restarting CTWM is probably not the real cause of the
problem.

 >     // zoom zoom-v zoom-h BEGIN
 >
 >   1 (frame-geometry)
 >   2 ;; initial window frame parameters
 >   3 ;; => ((outer-position 629 . 104) (outer-size 674 . 678) (external-border-size -3 . -3) (outer-border-width . 0) (title-bar-size 0 . 6) (menu-bar-external . t) (menu-bar-size 674 . 28) (tab-bar-size 0 . 0) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 672 . 36) (internal-border-width . 1))

These values are fishy - here I get for an initial emacs -Q Lucid frame

((outer-position 0 . 0) (outer-size 764 . 885) (external-border-size 5 . 5) (outer-border-width . 0) (title-bar-size 0 . 14) (menu-bar-external . t) (menu-bar-size 754 . 31) (tab-bar-size 0 . 0) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 752 . 36) (internal-border-width . 1))

An external border size of -3 can only harm.  The menu bar width should
be the outer frame width minus twice that of the external borders - 764
minus 10 gives 754 here.  Similar for the tool bar where you should also
subtract twice the internal border width.  We have to find out the cause
for this but I don't yet know how.

Now two times 3 gives 6 which _could_ explain the 6 pixels width
decrease but it wouldn't explain the 11 pixels height decrease.

When with gdb in frame_geometry in xfns.c you put a breakpoint at the
line staring with an if below (it's line 6747 here)

   XGetGeometry (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
		&rootw, &x_native, &y_native, &native_width, &native_height,
		&x_border_width, &ign);
   /**   XGetWindowAttributes (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), &atts); **/
   if (!FRAME_PARENT_FRAME (f))

run -Q and evaluate (frame-geometry) in the emacs you run, the
breakpoint should be hit.  If you now type

p x_border_width

in the debugging buffer, what does it print?

 >    => 8  _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN
...
 >    => 8  _NET_WM_STATE(ATOM) =


 >    => 8  _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ
...
 >    => 8  _NET_WM_STATE(ATOM) =

We have to find out who resets them.  Can you try doing this for any
other GUI application that can be made fullscreen via F11?

martin