closed thunderbird from maximization, restarted,then the window appeared in the upper left corner at the first non-maximization

[ffs-akl]

This issue is not caused by the fixing of #2183, Regardless of whether #2183 is fixed or not, it is always there.

R-2024-09-30T07-06-13.mp4

the output message of command WAYLAND_DEBUG=client /usr/bin/thunderbird 2> log1.txt
log1.txt

the output message of command WAYLAND_DEBUG=server labwc -C /tmp -s thunderbird -d 2> log2.txt
log2.txt

[tokyo4j]

Hmm... I don't know how to fix this / whether we should fix this. When thunderbird is launched in maximized state, labwc doesn't know the natural windowed geometry is, so when the window is unmaximized, labwc lets thunderbird submit a window geometry it wants. However, when thunderbird delays to submit the windowed geometry, labwc forgets about the unmaximize event it sent. Then when thunderbird finally submits the windowed geometry, labwc sees as if thunderbird submitted a new window geometry without labwc's intention and just updates the window size without updating its position.

So while #2183 was clearly a bug caused by the workaround for Qt apps, this one is a problem of how labwc perceives clients' states and I'm not sure we can/should fix this. It will be worth looking at implementations of other stacking compositors.

[jlindgren90]

Hmm. This is an interesting corner case. Maybe we should use some kind of falllback position if we get to the configure timeout with the unset (0x0) pending geometry - I think that's what happens here.

[jlindgren90]

By the way, the cpulimit utility is helpful to reproduce this.

[ffs-akl]

@tokyo4j @jlindgren90 thank you!