XDG configure state gets out of sync when clients timeout about labwc

[jlindgren90]

IIRC the "Window geometry for client (%s) appears to be incorrect - ignoring" is probably a client side bug. The client updated one or the other of window geometry/surface size but not both in sync. There were reports of this occuring with some Qt apps. I never saw it personally.

The timeout, I think, was added earlier. We need that to avoid a poorly behaving app from hanging up window movement/resizing.

I don't have time to try to reproduce or debug anything myself right now.

[johanmalm]

It's not obvious to me what the problem is here.

The timeout was originally added in this PR which contains quite a lot of info: https://github.com/labwc/labwc/pull/803/files

This issue might be related: #1902

What version of firefox are you using? I can replicate the kiosk issue with >=126

[johanmalm]

#803 (comment)

There is another problem (in the current code) which can be seen when attempting to tile an xdg-shell view that doesn't allow resizing. Example: the "about" window of xfce4-terminal. In that case, we never get a commit acknowledging the configure-request, and it remains "pending" indefinitely until an unrelated commit. As a result, we delay moving the "about" window to its tiled location, until the mouse cursor is moved over it -- then it suddenly jumps.

This presumably started occurring after ecd03b7 (haven't verified). To fix it, I would suggest a timeout (100 ms?) after which, if we haven't received the acknowledgement commit, we move the view anyway.

In hindsight, it may be better to check if max-size == min-size (which IIRC is the way we should disallow window resize on Wayland).

See comment here: #1294 (comment)

@jlindgren90 - Any thoughts? Can you remember if there were other reasons for the timeout?

[Consolatis]

History of the "window geometry for client .. appears to be incorrect":

• #1194 (comment)
• #1229

[jlindgren90]

@cillian64 since you said:

I'm happy to try fixing this myself if I can get some guidance on context/strategy.

I have some questions I would suggest investigating (and I am curious myself).

4. labwc discards the pending configure and assumes Firefox is still in state A.

What do you mean by "state A" here? Just the window/surface size?

5. Firefox eventually applies the configure and is now in state B

If "state" refers to window/surface size, then labwc should see the resize happen when Firefox eventually "applies the configure". When that happens, handle_commit() (xdg.c) should be called. Both view->current and view->pending should be updated to the new surface size ("state B") since the pending configure timed out already. Can you check if that's happening?

6. Toggle window maximization, Firefox window size changes from B to A
7. labwc thinks Firefox is already in state A so doesn't bother sending a configure

I am not following this part. How did the Firefox window size change if labwc didn't send a configure? Did Firefox resize spontaneously?