steam-for-linux
steam-for-linux copied to clipboard
ValveSoftware
New Steam UI notifications steal focus on Wayland
Your system information
- Steam client version (build number or date): 1683078372
- Distribution (e.g. Ubuntu): Fedora 38
- Opted into Steam client beta?: Yes
- Have you checked for system updates?: Yes
Steps for reproducing this issue:
- Focus any input field in any application
- Wait until notification pops up
- The notification steals the focus
I'm definitely not an X11 ATOM expert but when running a xprop on the notifications, the WM_TAKE_FOCUS ATOM is in-use.
On the topic of notifications, providing a toggle in the settings to use the system notification daemon would be nice. Would make it easier to dismiss and control where notifications appear :)
This is very annoying... specially when you are in the middle of writting some text but a chain of notifications suddently come up and interrupt you mid-typing.
Using sway, I tried to retrieve the information from the window to at least be able to capture it and remove its focus in the configuration of the window manager. But for some reason I was unsuccessful, since it looks like I can't properly select the notification window for some reason.
Has anyone at least been able to get some details that can be used to filter the window out? such as the window class / role?
This bug has still not been fixed in the recent stable release and it is happening as I type this comment.
I think for most Wayland WMs there's some way to make it so that it never get focused and rendered as an overlay layer.
I have tested Hyprland aswell and it has the same problem as Sway. GNOME on Wayland doesn't seem to have any of these issues, though.
Still present and not exclusive to Wayland, it is happening on X too.
According to window manager logs, Steam spawns a stray window with title = "None" and kills it 20 ms later.
This is extremely annoying, it steals focus and shifts all windows on any tiling window manager.
I attempted to make floating window and group rules as a workaround, but for some reason, Qtile could not match name="None" even by itself.
The logs don't reveal the instance or class, so the (empty) title is all that can be used to try and filter it--hopefully successfully.
Edit: With my nasty hack of doing while true; do xprop -name None; done, I was able to find a bit more information:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0x3200347
Serial number of failed request: 567
Current serial number in output stream: 567
It also happens on X with XFWM (stacking window manager), although it sometimes just stops happening too. Haven't found a reliable way to reproduce it.
Most often it occurs after launching Steam. As @purplebar0 pointed out, the notification that's disappearing and spawning said error in the log, steals the focus temporarily. However, even though the previous focused window receives focus again, it isn't actually received "completely". What I mean by this, is despite you thinking the window has focus, you won't be able to type anything in said window without first alt-tabbing to a Steam-owned process, then tabbing back again. This can be annoying if you're working in a text-editor for instance, since suddenly you won't be able to input anything until you've tabbed in and out. And this is necessary every time a notification disappears
This started happening after the beta got pushed to the stable branch. It wasn't always an issue with the beta. Or maybe it was and I just got lucky for not having encountered it, seeing it doesn't always happen
However, even though the previous focused window receives focus again, it isn't actually received "completely".
What I mean by this, is despite you thinking the window has focus, you won't be able to type anything in said window without first alt-tabbing to a Steam-owned process, then tabbing back again.
This is part of a different issue which can be reproduced by switching back and forth from the Chat window, where the text field remains active after switching from the Chat window.
On 18 June 2023 07:05:00 UTC, "Hu - notifications at github.com" @.***> wrote:
It also happens on X with XFWM (stacking window manager), although it sometimes just stops happening too. Haven't found a reliable way to reproduce it.
Most often it occurs after launching Steam. As @purplebar0 pointed out, the notification that's disappearing and spawning said error in the log, steals the focus temporarily. However, even though the previous focused window receives focus again, it isn't actually received "completely". What I mean by this, is despite you thinking the window has focus, you won't be able to type anything in said window without first alt-tabbing to a Steam-owned process, then tabbing back again. This can be annoying if you're working in a text-editor for instance, since suddenly you won't be able to input anything until you've tabbed in and out. And this is necessary every time a notification disappears
This started happening after the beta got pushed to the stable branch. It wasn't always an issue with the beta. Or maybe it was and I just got lucky for not having encountered it, seeing it doesn't always happen
-- Reply to this email directly or view it on GitHub: https://github.com/ValveSoftware/steam-for-linux/issues/9458#issuecomment-1595998934 You are receiving this because you were mentioned.
Message ID: @.***>
Update: This does not only affect notifications, but any windows that are to be closed. Tested with the Steam Settings window.
On Qtile + Picom, it is super annoying even on Max layout because ~~smooth window transitions~~ (edit: even with no animations!) have to display that stray invisible window and it ends up being a flashing window.
If you run with this environment variable set do those windows go away for you:
STEAM_DISABLE_BROWSER_SHUTDOWN_WORKAROUND=1 steam
If you run with this environment variable set do those windows go away for you:
STEAM_DISABLE_BROWSER_SHUTDOWN_WORKAROUND=1 steam
Yes! The windows don't instantly close, but at least the annoying side-effect of the workaround isn't present any longer.
Just to confirm, does the env fix both the flashing and the focus issue, or just one of them?
Can't confirm. Never had the flashing issue, and the env var doesn't fix the focus issue either. Using sway, fwiw
Just to confirm, does the env fix both the flashing and the focus issue, or just one of them?
I can confirm that it fixes both in my case (Qtile WM).
Using an AMD GPU, I can confirm that today's beta disables the workaround without requiring the environment variable.
Using an AMD GPU, I can confirm that today's beta disables the workaround without requiring the environment variable.
Still an issue for me on sway. Haven't tried the env variable though
I'm using Sway too, the issue is not fixed for me in the latest beta and the environment variable doesn't seem to help either.
I am on bspwm on X and still have this issue. The env variable seemed to work.
As a workaround for sway, has had any success with no_focus?
I'm trying no_focus [class="steam"] right now, but I con't confirm it works yet.
Update to my previous comment - as far as I can tell, it works well enough for a temporary solution. I have noticed some weirdness potentially caused by the workaround, but haven't had enough time to know if they are consistently occurring.
no_focus [class="steam"] didn't make any difference to me, and notifications still block focus :disappointed: ... I'm just disabling notifications in steam instead, but I reenabled them to test if the no_focus works.
I'm still having this issue with the Steam Client Beta, using KDE on X. Seems to be related to #9716
Oddly this same thing happened to me when I used X11. When I switched to Wayland, it didn't do it anymore, but recently I upgraded to Ubuntu 23.10 and it now does this on Wayland. I haven't tested X11 since I upgraded, so I don't know if it still does it there anymore.
EDIT: Tested, still happens on X11.
Fixed for me by adding following rule to my hypr.conf:
windowrulev2 = noinitialfocus, title:(^notificationtoasts.*)
Fixed for me by adding following rule to my hypr.conf:
windowrulev2 = noinitialfocus, title:(^notificationtoasts.*)
Sadly I can't confirm this working.
