search

swaywm / sway

i3-compatible Wayland compositor
https://swaywm.org
MIT License
14.76k stars 1.11k forks source link

for_window criteria are not executed when a window's floating state changes #6137

Open xPMo opened 3 years ago

xPMo commented 3 years ago

Running Sway and i3 with the following config:

exec alacritty
for_window [floating] border pixel 2
for_window [tiling] border normal 2

i3 will change the border when changing the windows floating state. Sway will not (but will if the window title changes).

$ swaymsg -t get_version | jq -r .human_readable
1.6-rc2-a9563a37 (Mar 24 2021, branch 'makepkg')

Related: PR #5323, possibly others. There is a comment on that PR which is incorrect, as i3 does execute for_window criteria on window state changes. Example from the i3 user docs:

# makes the window floating as soon as I change
# directory to ~/work
for_window [title="x200: ~/work"] floating enable

However, both i3 and Sway will only apply each criteria once per window (which makes something like my sample config not as useful in either i3 or Sway).

Basically, for_window criteria are kind of broken and unintuitive in i3 anyway (trigger on window mapping or state change, but only if that criteria hasn't yet been triggered for the given view).

xPMo commented 3 years ago

Also ref i3/i3#4346

I understand some reasoning why criteria are only applied once: Suppose a title-based criteria is triggered (like the one in the i3 docs), and then a user manually re-tiles the window. If the title is re-set (to the same title), the window will not re-float because of the only-once rule.

thuck commented 3 years ago

Allowing the trigger to happen when the title changes would be very good, and would help with some softwares like slack that set a title and modify it a little later.
Slack will create a window with the title Slack and a little later will change that to another pattern.
For example for calls, slack will create a mini panel window; that window will contain the title Slack and after a very short time it will change to mini panel, but at that point it is to late to apply the criteria.

xPMo commented 3 years ago

Allowing the trigger to happen when the title changes would be very good, and would help with some softwares like slack that set a title and modify it a little later.

It already does. That case should already work. This issue is that i3 also triggers on floating state, while Sway does not.

thuck commented 3 years ago

From my tests it doesn't work; maybe something specific with xwayland?

thuck commented 3 years ago

I guess the problem is the floating state; the mini panel is a floating window...

runbmp commented 3 years ago

I have the same issue with chromium screen sharing. The title is changed after the fact, so I can't use for_window (that I can tell). It would be cool to do something like always_for_window instead!

spiralman commented 3 years ago

I'm having a similar problem, also with Chrome (but, I suspect this is common to any application that has tabs internally and re-titles the window to match the tab title):

I want Chrome to have inhibit_idle when I'm using Google Meet, but not for any other tabs. If I do:

for_window [class="Google-chrome" title="^Meet - .* - Google Chrome"] inhibit_idle visible
for_window [class="Google-chrome" title="^(?!Meet)"] inhibit_idle none

My desired workflow is to join a meeting, move the tab to a new window (at which point I want inhibit_idle) then close the window (and nothing should have inhibit_idle anymore). It works correctly once, but, after that, the inhibit_idle gets "stuck" on the original chrome window, even if meet isn't there.

It'd be nice to have a way to design "reactive" settings like that, without having to spawn off another process to watch for changes.

xPMo commented 3 years ago

It would be cool to do something like always_for_window instead!

It'd be nice to have a way to design "reactive" settings like that, without having to spawn off another process to watch for changes.

I would love to see such an extension! However, this issue is about the existing i3 compatibility wrt floating state changes.

choucavalier commented 3 years ago

Looking forward to this being fixed. Currently I cannot set the border to be different for floating windows than for tiled windows (for windows that are initially tiled and that I change to floating).

tusktenon commented 3 years ago

I think I have a related issue. For many windows (browsers, terminals, etc.), I want them to tile by default, but I also float them pretty frequently, and would like to specify their floating size. Since criteria are only executed once,

for_window [app_id="firefox" floating] resize set 50 ppt 90 ppt

doesn't work, because the window was initially tiled. Similarly,

for_window [app_id="firefox"] floating enable, resize set 50 ppt 90 ppt

works once, but if I tile the window and then re-float it, my size settings are lost.

Absent some form of persistent criteria checking, is there some other way I can specify a "default-size-when-floating"?

aacebedo commented 3 years ago

Got a similar issue. I am using Ferdi and wanted to get its window floating everytime it appears. The first time the app is started, its window is made floating as intended by the criteria. However if I close the window and reopen it by clicking the traybar icon, the window does not float anymore, the criteria is not triggered anymore even if the class or instance of he window didn't change.

forestchen1224 commented 1 year ago

Anything new here? Still not work for floating window when setting the opacity for_window [ floating] opacity set 0.5

trinitronx commented 1 year ago

Allowing the trigger to happen when the title changes would be very good, and would help with some softwares like slack that set a title and modify it a little later.

This may also affect some browser extension windows. I'm not 100% sure, but could be related due to some rules applying on floating state change, sometimes... or else maybe this is another bug due to the additional redraw problems complicating it? I tested this with LastPass extension in Firefox (native sway windows) with the following setting checked: "Open extension pages (like this one) in new dialog". This setting causes most LastPass windows to open as full windows instead of browser tabs. The idea here was to set certain LastPass windows based on title to floating & specific sizes. However, the actual behavior of Sway seemed very buggy.

The for_window rules tested were:

for_window [app_id="firefox" title="Extension.*LastPass.*(?:Reprompt|YubiKey Multifactor Authentication).*"] floating enable
for_window [app_id="firefox" title="Extension.*LastPass.*Reprompt.*"] resize set width 460px height 460px
for_window [app_id="firefox" title="Extension.*LastPass.*YubiKey Multifactor Authentication.*"] resize set 800 300

for_window [app_id="firefox" title="Extension.*LastPass.*Edit secure note.*"] resize set 600 400
# The following rule could also be "floating enable", 
# with similar yet slightly different buggy behavior
for_window [app_id="firefox" title="Extension.*LastPass.*Edit.*"] floating disable

The result is very buggy behavior, which could indicate some race condition with when title is set (or simply some coordinates or sizes are wrong on redraw?)

YardQuit commented 11 months ago

Is this a pretty much dead project nowadays? I still have these issues.

SoumyaRanjanPatnaik commented 5 months ago

Allowing the trigger to happen when the title changes would be very good, and would help with some softwares like slack that set a title and modify it a little later.

This may also affect some browser extension windows. I'm not 100% sure, but could be related due to some rules applying on floating state change, sometimes... or else maybe this is another bug due to the additional redraw problems complicating it? I tested this with LastPass extension in Firefox (native sway windows) with the following setting checked: "Open extension pages (like this one) in new dialog". This setting causes most LastPass windows to open as full windows instead of browser tabs. The idea here was to set certain LastPass windows based on title to floating & specific sizes. However, the actual behavior of Sway seemed very buggy.

The for_window rules tested were:

for_window [app_id="firefox" title="Extension.*LastPass.*(?:Reprompt|YubiKey Multifactor Authentication).*"] floating enable
for_window [app_id="firefox" title="Extension.*LastPass.*Reprompt.*"] resize set width 460px height 460px
for_window [app_id="firefox" title="Extension.*LastPass.*YubiKey Multifactor Authentication.*"] resize set 800 300

for_window [app_id="firefox" title="Extension.*LastPass.*Edit secure note.*"] resize set 600 400
# The following rule could also be "floating enable", 
# with similar yet slightly different buggy behavior
for_window [app_id="firefox" title="Extension.*LastPass.*Edit.*"] floating disable

The result is very buggy behavior, which could indicate some race condition with when title is set (or simply some coordinates or sizes are wrong on redraw?)

* Some windows float and resize as they are supposed to, but the resize & float seem delayed

* Some windows don't float or resize correctly, and the inner window content looks as if it's drawn incorrectly

  * Only the very bottom left of the window contents are drawn
  * Yet they're drawn inside a small square "viewport" that's packed into the upper top left of the Sway window (when `floating disable` is used in `for_window` rule)
  * See this screenshot for what this looks like: ![swappy-20231112_131500](https://private-user-images.githubusercontent.com/122524/282323554-b95d9a19-b99c-41e8-abd1-e5d89a52511f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTc2ODM1NjIsIm5iZiI6MTcxNzY4MzI2MiwicGF0aCI6Ii8xMjI1MjQvMjgyMzIzNTU0LWI5NWQ5YTE5LWI5OWMtNDFlOC1hYmQxLWU1ZDg5YTUyNTExZi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNjA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDYwNlQxNDE0MjJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wYjJmMjg2MWE2OTUzNGRiZjk0Y2ViYjljZGZjMzcwYzE0Y2Y0Njc4NzViOWE0YjYwMjAzYjJlYzM5ZTM5OWYyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.Dcy8nAWTAuL9c5n9nVLV-1738NqrfmC3rMRPog6PRk0)
  * When this happens, toggling the window floating / non-floating forcibly using keybindings usually seems to force Sway to run the rules & the window redraws properly.

    * **Notice that in this case, Sway _does_ seem to apply rules on floating state change!** 🤷 🤔
  * When `floating enable` is used instead for the "`title="Extension.*LastPass.*Edit.*"` rule:

    * Similar to the above behavior, except the initial floating window is very small (seems to be only `95 x 95` pixels)
    * After moving the mouse, then the `600 x 400` pixel resize occurs
    * However, the parent Firefox window (the one which launched the LastPass "Edit" window) is now drawn incorrectly
    * See these screenshots for this behavior: ![swappy-20231112_133123](https://private-user-images.githubusercontent.com/122524/282324005-84d93ee0-33eb-441c-bee5-3faa6117c566.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTc2ODM1NjIsIm5iZiI6MTcxNzY4MzI2MiwicGF0aCI6Ii8xMjI1MjQvMjgyMzI0MDA1LTg0ZDkzZWUwLTMzZWItNDQxYy1iZWU1LTNmYWE2MTE3YzU2Ni5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNjA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDYwNlQxNDE0MjJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mZmZiMzIwYjdiYWYyNWUyNDI0MTk3MmU3MzdmOWU4MzQxMzczOGVkMDE1YmVjNDczNTk5OGYxZWY1OTc1NTYwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.s-OXg8YyxQ6DEB6B9O_qeNG9BHbS4tg6C80Cvc2FhCs)
      ![swappy-20231112_133331](https://private-user-images.githubusercontent.com/122524/282324088-8753f522-242a-48a7-9d3d-a882ff04743f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTc2ODM1NjIsIm5iZiI6MTcxNzY4MzI2MiwicGF0aCI6Ii8xMjI1MjQvMjgyMzI0MDg4LTg3NTNmNTIyLTI0MmEtNDhhNy05ZDNkLWE4ODJmZjA0NzQzZi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNjA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDYwNlQxNDE0MjJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT01YzZkYTBiMGEzZGFhYzQzMGIxNmJjODNjYjdiNzkxYWJhODFlNTc1NDNkZWY4MzExNjNmZDA4YWZmOTgxZDFjJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.8Oo9lkIjj7N6G_wjwLwZxoKRRTyFx47mYzvWb75c_OE)

I can confirm this. I think it might be useful to create a new issue to gain some traction since the problem that you've described seems different from what is written by OP.

trinitronx commented 5 months ago

For what it's worth: I have updated to Manjaro "unstable", and have not seen my particular window resize drawing problem occurring now.

My system is now running the following package versions:

It looks like sway 1.9 release says that there have been changes to the rendering code, using the new wlroots rendering API. So, maybe this fixed something w.r.t. these window resize + redraw race conditions?

:crossed_fingers: I'm hoping that things actually stay more stable this way, and so far this has been the case! :sweat_smile: In case the issue re-occurs, I will probably file a separate bug report as suggested by @SoumyaRanjanPatnaik