[wayland][sway] Windows don’t get given the right types (especially notifications), so some don’t float that should
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: me, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0
Steps to reproduce:
With MOZ_ENABLE_WAYLAND=1, under Sway (which, as a tiling window manager, makes the problem far more obvious than it’s likely to be under most compositors), open any window that shouldn’t be a regular tiled window, such as by these three means:
-
Trigger a file download prompt: e.g. open
data:application/octet-stream,in a new tab. -
Cause a notification to pop up: e.g. Ctrl+Shift+S to trigger the screenshot tool, choose a region, then hit the Copy button. (This is actually at least half of the subject of bug 1590909, though it’s not spelled out that it’s all notifications that are suffering here, which makes it radically more important than if it were just the screenshot tool.)
-
Open the About Firefox window. (This is actually already the subject of bug 1681158.)
(I will note that standard GTK pickers like file and colour do use the right window types, but I haven’t found any windows that are opened by Firefox itself handling all this properly.)
Actual results:
In each case, a full tiled window is opened. This is weird but not too big a deal on download prompts and the About Firefox window, but it’s disastrous in the case of most notifications, because when something in the background triggers a notification, it’ll steal focus and rearrange everything. (e.g. I have notifications enabled in Fastmail, so this’d happen every time I get a new email.)
Expected results:
The download window should have been a dialog window, not a normal window. (Also, it should have a title.)
The notification should have been a notification window, not a normal window.
The About Firefox window should have been something other than a normal window, not sure exactly which, but something that’d make it float.
Poor workaround for Sway users: notification windows have empty titles and main Firefox windows never do, so you can target notifications in your Sway config with [app_id="firefox" title="^$"]; I have this monstrosity in my Sway config:
no_focus [app_id="firefox" title="^$"]
for_window [app_id="firefox" title="^$"] border none, floating enable, move position 79 ppt 88 ppt
Unfortunately, download prompts also have an empty title, so if you do this, they’ll be positioned somewhere in the bottom right corner, half off the screen, and not initially focused.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
To fix that I'd need to know what exact 'type' do you mean here. Nightly should already use correct window roles (toplevel/dialog/popup), can you try that?
|
Reporter | |
Comment 3•3 years ago
|
||
I’m not sure what the correct terminology is, so I was guessing based on the CRITERIA section of sway(5)—sometimes treacherous due to deliberate i3 compatibility at the cost of Wayland purity!
So I don’t know the proper terms to express what I mean, but the effect is as I describe, that things like notifications get opened as full tiling windows rather than decorationless floating windows. Perhaps Nightly should already do the correct thing, but it doesn’t seem to be, and bug 1590909 and this /r/swaywm thread both describe the same problems two years ago. I’m guessing that either it’s been broken the whole time, or it got fixed and regressed.
I’ve never used any other Wayland compositor, but my impression is that in most compositors this might go unnoticed, because client-side decorations and only floating windows means that there could be no visible difference between what you call the toplevel/dialog/popup roles. I could easily be wrong in this. But in a tiling window manager, these things are rather critical for correct functionality.
Description
•