Windows change geometry when fvwm3 starts

[dumblob]

Upfront Information

• Fvwm3 version (run: fvwm3 --version)

fvwm3 1.0.5 (1.0.4-128-gc7b41a03)
with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

• Linux distribution or BSD name/version

Arch Linux

• Platform (run: uname -sp)

Linux 5.15.53-1-lts #1 SMP Fri, 08 Jul 2022 12:38:20 +0000 x86_64 GNU/Linux

Expected Behaviour

When starting fvwm3 e.g. from xterm I expect my windows to stay where they are and keep their dimensions if possible.

E.g. fvwm3 -v -o - -f "$XDG_CONFIG_HOME/fvwm-global/init.conf"

Actual Behaviour

Windows move by the thickness of the frame and title height offsets in x and y axes respectively. But they do not shrink therefore effectively crossing page boundaries for larger or maximized windows causing issues with focus, overlaps, and all kinds of nasty behavior and bad look 😉.

Enabling logging

[1657611025.772767] setup_window_placement: Expanding screen from 'null' -> ''

This is the only entry I get in the log. I get it always when I switch pages (I do not know the origin of this message, but I do have a hook when switching pages which just calls a function which counts all windows on the page I switched to but does nothing else).

Steps to Reproduce

1. run plain X with a terminal emulator
2. open some GUI apps from the terminal emulator by running them in the background
3. run fvwm3 in the terminal emulator with fvwm configuration which has non-zero borders and/or title (e.g. the default bundled configuration)
4. observe the existing windows changed geometry aka "moved" (probably due to reparenting not compensating for the border/title dimensions)

• Does the problem also happen with Fvwm2?

Yes.

Does Fvwm3 crash?

No.

Extra Information

• Anything else we should know?

A different behavior can be observed when replacing an existing window manager (incl. if it is fvwm3). If replacing an existing wm which added frames/title, windows first lose the frame/title and then move to the x,y position of the original window with frame/title. Therefore if fvwm3 then re-adds the frame/title and by coincidence the frame/title have the same thickness/height, then the behavior described in this bug does "cancel out" with the unexpected "move" after loosing the frame/title.

IMHO either X or some window managers (notably fvwm3) do the "move" after loosing its parent window on purpose but only sometimes. E.g. if I kill -9 fvwm3, then this "move" does not happen. But if I quit fvwm3 normally using the Quit command, then the "move" does happen.

[ThomasAdam]

This isn't a bug in fvwm. Can you post your config somewhere, and I'll take a look.

[dumblob]

Sure, I am experiencing this with the bundled default config (as I mentioned in the steps to reproduce above) - see https://github.com/fvwmorg/fvwm3/blob/master/default-config/config .

[ThomasAdam]

Hey @dumblob

Strange. I cannot reproduce this at all given your steps -- for me, unparented windows retain their geometry when fvwm3 starts, and they certainly aren't changing their geometry.

Perhaps though I'm still missing something -- would a short video of the problem be possible for me to see what's happening?