stop xwayland window misbehavior before/after ResizeTo and MoveTo actions

[bdantas]

I'm on labwc 0.7.0 and have various window rules in my ~/.config/labwc/rc.xml. The ResizeTo and MoveTo rules work for wayland applications ([xdg-shell] in Alt+Tab menu) but not for xwayland applications ([xwayland] in Alt+Tab menu).

I'm not sure if this is bug or a known limitation due to how labwc handles xwayland windows.

[johanmalm]

I've just tried MoveTo with xterm and it works fine here.

[bdantas]

Maybe my syntax is wrong? I'm trying to move Thunderbird (AppImage of an old gtk2 version) using this rule in ~/.config/labwc/rc.xml, just as an example:

<windowRules>
	<windowRule identifier="" title="Thunderbird"><action name="MoveTo" x="10" y="10" /></windowRule>
</windowRules>

Definitely not working for me. The window opens in the center of my laptop's screen. What gives?

P.S. I'll try with xterm to remove any confounding factors.

[bdantas]

The syntax is correct and it works with xterm.

Hmm, with Thunderbird (gtk2-based, xwayland app) and with Xfe (fox-based, xwayland app) ResizeTo and MoveTo do not work at all. Any ideas?

[johanmalm]

Are you sure the identifier / title is correct. Might not work with identifier="" Run labwc -d to see the identifier + title when you launch (map) an application.

[Consolatis]

Just a guess, maybe the title is not correct during startup and thus the Thunderbird rule doesn't match. You could try to use the identifier rather than the title, see wlrctl window list.

[bdantas]

Thank you both.

$ wlrctl window list
foot: foot
Thunderbird: Inbox - Mozilla Thunderbird

	<windowRule identifier="Thunderbird"><action name="ResizeTo" width="900" height="550" /><action name="MoveTo" x="10" y="10" /></windowRule>

Now it works!

I assumed the output of wlrctl window list were titles. What's the difference between "identifier" and "title" in this context?

[Consolatis]

I assumed the output of wlrctl window list were titles. What's the difference between "identifier" and "title" in this context?

The title may change randomly, for example in thunderbird it looks like you'd get a new title when you change the folder. The identifier (or app_id / WM_CLASS) is usually the same during the runtime of the application.

Edit: Just to clarify, you could likely still use the title with something like title="*Thunderbird*" but I'd always recommend to only use the identifier unless there are reasons not to (for example when you only want to match a specific window of a multi window application).

[johanmalm]

I assumed the output of wlrctl window list were titles. What's the difference between "identifier" and "title" in this context?

Depends on the client. If you run labwc nested (from the terminal) you can see what they are.

[bdantas]

Thank you both very much--not only for helping me solve my issue, but also for sharing your knowledge. Many thanks! Happy hacking!

[bdantas]

Darn, I found another unexpected behavior related to this.

Here is the rule:

	<windowRule identifier="" title="Write:*"><action name="ResizeTo" width="800" height="400" /><action name="MoveTo" x="300" y="200" /></windowRule>

Here is relevant output from wlrctl:

$ wlrctl window list
foot: foot
Thunderbird: Write: (no subject)
Thunderbird: Inbox - Mozilla Thunderbird
brave-browser: ResizeTo and MoveTo actions not working for xwayland windows · Issue #1446 · labwc/labwc - Brave

Rule works when I compose first email in Thunderbird. When I go to compose second and subsequent emails, the window with "Write:*" in the title is the correct size but opens at location 0,0 (at top-left corner, with titlebar and minimize/maximize/close buttons off the screen). I tried using "identifier" instead of "title" in the rule, but it didn't help. Any ideas what's going on here?

[johanmalm]

matchOnce?

https://labwc.github.io/labwc-config.5.html#entry_matchonce

[Consolatis]

Not sure why this is happening. In general I'd suggest using SnapToRegion rather than the ResizeTo and MoveTo combination.

[bdantas]

Thanks for the tip, but no luck. I tried rule with matchOnce="false" as well as with matchOnce="true", both times got the same unexpected behavior (MoveTo action working only on first email that I write).

I'll give SnapToRegion a try.

[bdantas]

SnapToRegion works reliably, but only if I don't move the window. If I do move it, subsequent "Write" windows open at 0,0.

I have a theory: I think this is Tbird interfering by trying to "help" the user by remembering where the Write window is moved to. Whatever algorithm Tbird is using for window location doesn't work in Xwayland, so window ends up at 0,0 when Tbird tries to move the window to the place it was last moved to.

For whatever reason, SnapToRegion is able to put the window where user wants it to be, without Tbird being able to detect that the window was moved.

[bdantas]

I experimented a lot more and can confirm that Thunderbird is interfering by trying to move windows to where they were last moved to, but is doing so using incorrect coordinates. There does not seem to be any Thunderbird setting that disables this annoying behavior, despite many settings with promising names in the advanced configuration editor (about:config).

Is there any window rule that makes labwc take full control of window placement, forbidding applications from interfering? If not, maybe there a way to introduce a slight delay before a windowRule action (so that labwc moves/resizes the window after the application has done so)?

[ahesford]

Seems to me the best solution would be kicking Thunderbird to the curb. 🤣

I recently discovered a use case for a Delay actions which could hack around some misbehaviors. Not sure about the others, but I could be persuaded that such an action has value.

[bdantas]

Seems to me the best solution would be kicking Thunderbird to the curb. 🤣

I've considered that. All GUI email clients are terrible, but so far I've found Thunderbird to be the least terrible.

Regarding a Delay action, I'd really love it. I don't want to fight with buggy applications or swap them out. I'd rather just trample on their misbehavior with window rules.

[Consolatis]

Maybe we could add something to window rules that prevents X11 applications from requesting their own position. AFAIR we already support ignoring focus requests to fight misbehaving X11 applications.

A Delay action feels like a pretty hacky workaround.

[bdantas]

Maybe we could add something to window rules that prevents X11 applications from requesting their own position.

Hi Consolatis. I think that would be the ideal way to deal with this particular kind of misbehavior (including my specific issue). I'd be happy to test any patches but am not competent enough with windowing/wayland to implement this.

[bdantas]

As mentioned above, some xwayland windows (e.g., Thunderbird's "Compose" window) seem to move/resize themselves after labwc has put it where window rules dictate.

I found a different but related misbehavior: Some xwayland windows (e.g., any Xfe file manager window) appear for a split second before labwc applies the ResizeTo and MoveTo actions. This has a jarring effect on the user.

Both kinds of misbehavior could be prevented by a window rule that prevents X11 applications from requesting their own position. I reopened the issue now that we've fleshed it out a bit.

[Consolatis]

Feel free to give https://github.com/Consolatis/labwc/tree/feature/ignore_x11_configure_request a try. Not tested at all.

[bdantas]

Hi, Consolatis. I tested this commit and it did solve a long-standing Thunderbird misbehavior regarding placement of "Write" window. Thank you, a little rock in my shoe is finally gone!

However, the commit did not fix the small issue where Xfe file manager windows open for a split second in one size (per Xfe's config file) before labwc applies a ResizeTo action. This is purely cosmetic so not a big deal.

[johanmalm]

@Consolatis That patch looks good to me.

[Consolatis]

However, the commit did not fix the small issue where Xfe file manager windows open for a split second in one size (per Xfe's config file) before labwc applies a ResizeTo action. This is purely cosmetic so not a big deal.

Yeah, I've seen that one as well when using SnapToEdge in a window rule. Maybe we need to call the window rules before enabling the scene node on the first map instead of after. Not quite sure. Would deserve its own issue.

[bdantas]

Maybe we need to call the window rules before enabling the scene node on the first map instead of after. Not quite sure. Would deserve its own issue.

Done. See https://github.com/labwc/labwc/issues/1718

Thanks again for ignoreConfigureRequest!

[Consolatis]

Lets leave this open until the ignoreConfigureRequest thingie (or a variation thereof) is actually merged.