Open ghost opened 11 years ago
Same here. "Focus follows mouse" on.
I have the same issue as #64, running awesome with focus-follows-mouse.
Same problem with awesome here. The default rc.lua had code to focus a window when clicking on it and also on mouse-over. Commenting out the mouse-over part solves the problem with the right-click menus hiding on mouse-out, but leaves the main menus unclickable as before. Only after also commenting the focus on click the main menus work. But now I can only focus a window with the taskbar and Mod+j/k.
UPDATE: It seems that just registering a client unmodded button with empty handler with the Steam window will cause the main menus to become unclickable. Probably when you click the menu button Steam opens and focuses the menu, but then awesome focuses the main window again. I agree with OP that those menus should not be registered as normal windows. But then again, this is a glx app, not a normal X app... I remember Google Earth had exactly the same problem.
Solution for awesome: not register the client button with Steam. Make your awful.rules look like this (all windows will still focus on click, except steam):
steambuttons = awful.util.table.join(
awful.button({ modkey }, 1, awful.mouse.client.move),
awful.button({ modkey }, 3, awful.mouse.client.resize))
clientbuttons = awful.util.table.join(
awful.button({ }, 1, function (c) client.focus = c; c:raise() end),
awful.button({ modkey }, 1, awful.mouse.client.move),
awful.button({ modkey }, 3, awful.mouse.client.resize))
awful.rules.rules = {
{ rule = { }, except = { class = "Steam" },
properties = { buttons = clientbuttons } },
{ rule = { class = "Steam" },
properties = { buttons = steambuttons } },
{ rule = { },
properties = { border_width = beautiful.border_width,
border_color = beautiful.border_normal,
focus = true,
keys = clientkeys } },
UPDATE: and to fix the mouse-out context menu hiding issue just add an exception like this:
-- Enable sloppy focus
c:add_signal("mouse::enter", function(c)
if awful.layout.get(c.screen) ~= awful.layout.suit.magnifier
and awful.client.focus.filter(c) and c.name ~= "Steam" then
client.focus = c
end
end)
And now everything is ok. That's why I like awesome, I can fix such issues myself :)
There was also some discussion of a likely related issue on wmii: http://steamcommunity.com/app/221410/discussions/1/846938350833390522/
I would also note that Steam menus do not grab the mouse - I'm not entirely sure what the standard way for menu widgets to work is, but AFAICT they all involve grabbing the mouse.
The next client release has some changes which should improve the situation here. We haven't done extensive testing with focus-follows-mouse but we've resolved a bug in the menu focus handling which would affect it in addition to click-to-focus.
Cool, after the latest update the menus are working much better on wmii. They disappear immediately when the mouse is moved off them (not sure if that is intentional or not - it certainly differs from the behaviour of other applications), but I can now use them without having to switch to a different tag.
Menus drop when steam loses focus, that's expected. That's so if you switch away when you have a menu up it will get closed properly. Focus-follows-mouse doesn't cooperate well with that, of course, and potentially we should be looking at some other kind of activation instead of focus, but everything we have is built around focus right now.
I confirm that all menu problems on awesome wm have been solved with the new Steam. Even the auto close on mouse out has been cleared. This may also have to do with the new version of awesome, there's some focus related stuff changed in rc.lua.
Confirmed, menus now seem to be working fine with focus-follows-mouse. Thanks!
For some reason, with the new steam-client update I started having this issue (which I didn't have/notice before) with Xmonad ... So for me it's a regression :-(
Got the a client update today (the build from Jan 25) and nothing changed for me. Menu focus handling is still broken.
I think the central issue is, that the WM has to be informed, that there is a menu open, so it doesn't change focus regardless where you move the cursor on the screen. This is how other applications work.
This happens if the window focus mode in Gnome 3 is set to either 'Sloppy' or 'Mouse' mode, rather than the standard click (changeable via dconf or gnome-tweak-tool). I think Steam is failing to let the window manager know something.
Same here, Gnome 3 follow focus mode ON.
same here: gnome 3.8, sloppy focus
I also encounter this issue with gnome-shell 3.8.3. I use sloppy focus because it's the only one that jives well with having multiple monitors and using workspaces extensively.
Only solution is to select the menu and then use keyboard navigation therein. That would be extremely compromising for anyone with vision issues, though, as you cannot move your mouse when doing this.
i'm using xmonad + gnome3 + ubuntu 13.04 amd64. every time i right click on a game to bring up a context menu, it immediately closes on me.
Ubuntu 13.10/14.04 GNOME 3.8-3.11 issue still exists.
Ubuntu 13.10 Gnome Shell 3.8.4. Issue still exists for me as well.
I'm also experiencing this issue in Gnome3 (3.8-3.10) and it's very frustrating.
Same here, Fedora 20 with both Gnome 3.10 and new Gnome 3.12
I am experiencing the same problem on Ubuntu Gnome (3.6) and Arch Linux with Gnome 3.10, 3.12. The way to use a menu is to first open it with the mouse and select with arrow keys. A very frustrating situation.
+1 @tvn87 I'm using arrows too
Same here, Fedora 20 with both Gnome 3.10 and new Gnome 3.12, sloppy focus.
Maybe related to #2355 ?
This issue appears to be (partially?) fixed in that the menus are now shown correctly: here, their opacity is set by xfwm4 to the value of its pop-up windows opacity setting. (I've checked with different values; the change in appearance is consistent with the value chosen.)
Client build dated 2014-08-13.
Functionality-wise they still appear to be broken in the 2014-08-13 build (at least for me). The menus still close while hovering over them.
On Steam Build Aug 22 2014, at 15:31:16 I have still the old trouble on Arch Linux with Gnome 3.12. Have the following setting in dconf:
org.gnome.desktop.wm.preferences.focus-mode = mouse
I've been having this problem for years and just got used to using arrow keys to select from menus. However, I'm now seeing behavior like #3489 when I right-click (e.g. to uninstall a game). The only work-around I've found is to temporarily switch my focus mode to click.
What I don't understand is why my window manager thinks the menu is a new window? Shouldn't it just be a widget like a text field or button? Also, doesn't Steam use WebKit to drive the UI? Why didn't I see this problem in Chrome before they forked it as Blink?
I'm on Ubuntu 14.10, Gnome 3, Steam built 2015-04-13 15:20:04.
Because to X11, everything is a window: http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation
@rdeforest, I'm on Steam beta channel and Ubuntu 15.04 (with Unity currently), for quite some time I do not experience this issue at all. Seems to be fixed in Ubuntu or Steam itself, try to update to 15.04 (I live on nightly builds, so, probably it was fixed somewhere during 15.04 development process).
Nice! I'll switch to the beta channel when I get home. Thanks for the info! On Apr 27, 2015 9:47 AM, "Nazar Mokrynskyi" notifications@github.com wrote:
@rdeforest https://github.com/rdeforest, I'm on Steam beta channel and Ubuntu 15.04 (with Unity currently), for quite some time I do not experience this issue at all. Seems to be fixed in Ubuntu or Steam itself, try to update to 15.04 (I live on nightly builds, so, probably it was fixed somewhere during 15.04 development process).
— Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/steam-for-linux/issues/6#issuecomment-96736203 .
Yes, the beta has improved significantly in this area, though I'm not sure exactly which change[s] did it.
A few other issues seem to have [almost] gone away too. I used to have major problems with menu items getting stuck half-faded in if I moved out of them too quickly. They then covered everything and prevented screen updates in the covered area. Workaround: find the menu item which was opened, mouse over it again until the menu fades in completely, and then move the mouse and it'll go away properly.
Most links in text content (articles, reviews, etc) used to be unclickable, they now work as they should.
Confirmed that Ubuntu 15.04 and Steam Beta channel play well together. The upgrade to 15.04 seems to have fixed an Xorg focus bug: https://bugs.freedesktop.org/show_bug.cgi?id=26213. I suspect they are related and that whatever the Xorg people did helped (Steam Beta was still broken for me on 14.10).
On Mon, Apr 27, 2015 at 10:41 AM, Henrik Danielsson < notifications@github.com> wrote:
Yes, the beta has improved significantly in this area, though I'm not sure exactly which change[s] did it.
A few other issues seem to have [almost] gone away too. I used to have major problems with menu items getting stuck half-faded in if I moved out of them too quickly. They then covered everything and prevented screen updates in the covered area. Workaround: find the menu item which was opened, mouse over it again until the menu fades in completely, and then move the mouse and it'll go away properly.
Most links in text content (articles, reviews, etc) used to be unclickable, they now work as they should.
— Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/steam-for-linux/issues/6#issuecomment-96753294 .
"I like dark beer, dry cider, peaty scotch, añejo tequila, floral gin, expensive vodka, and cheap rum." -- A. P.
I still sometimes have this issue, reproduced it today with latest Steam Beta update, in Enlightenment 19.9 on Arch with Xorg at version 1.17.1. It seems to be much more difficult to trigger it though and it only happened a few times and then stopped (same instance of Steam still running).
The way to reproduce it was to Alt+Tab away from Steam just after hoovering something which shows a menu or other popup. The popup starts to fade in but gets stuck on top of everything else until I hoover the same UI item again.
Arch Linux, xfwm 4.12, focus follows mouse, xorg-server 1.17.2-4. Steam client from 7 Oct 2015.
However (workaround?) if you move the mouse onto STORE, and to any other pulldown (LIBRARY, COMMUNITY, or even onto one of those then back onto STORE), and then you can use those menus without issue.
Behavior is not random; this can be triggered every time.
This issue is almost eight years old and yet I'm still experiencing it.
I am using Linux Peppermint x64 (latest) and the issue is with the dropdown menus that appear when moused over. I have window focus setting set such that simply mousing over the window won't take focus, but any other mouse action (including scrolling) will.
The behaviour is as follows:
1) I hover over the menu item (or click on the menu items at the very top) 2) The submenu appears, !! and takes the focus from the main steam app as if the menu was an app itself. !! 3) I scroll while my mouse is still over the main menu and not the submenu, and the submenu disappears while the focus is given back to the main menu.
I can confirm that similar menus in other applications do not have this issue, and I am inclined to agree with one of the original comments which suggests that "Steam seems to use the wrong X11 window type (top level window instead of pop-up menu window) to draw its menus, so the main Steam window loses focus when opening a menu. Additionally Steam closes the menu window as soon as the menu window loses its focus."
This has been an issue for 9 years now, and it still hasn't been fixed. Come on Valve. With the Steam Deck coming out, there has to be a renewed effort to clean up these bugs on the Steam Linux client.
This issue still occurs on the latest Steam beta, built 23 Sep 2021. I'm running Manjaro GNOME, and I use "click to focus". Even so, when I open a menu, the Steam window loses focus.
oh yeah. i've been experiencing this so long i thought it was a planned feature
Steam Version: 1690583737 Steam Client Build Date: Fri, Jul 28 11:44 AM UTC -08:00 Steam Web Build Date: Fri, Jul 28 3:21 PM UTC -08:00 Steam API Version: SteamClient020
Still happens in 2023. Gnome 43.4 on Debian/Bookworm. Workaround is to just turn on click-to-focus to access right-click, but it sure would be nice to just be able to use right-click menus in steam with sloppy focus.
EDIT: I forgot to add, this would be less of a pain if arrow keys could move/select things in the menus, but they don't seem to respond to those keys, aside from Esc to close.
Same here also with sloppy focus on Mint/Cinnamon.
Steam Version: 1696019606 Steam Client Build Date: Fri, Sep 29 7:38 PM UTC -08:00 Steam Web Build Date: Fri, Sep 29 10:25 PM UTC -08:00 Steam API Version: SteamClient020
I'm shocked that this report is almost 12 years old and apparently there's been no move to address it.
Debian bookworm, using fvwm3 with focus follows mouse. I can't get at the contents of any of the steam client menus.
I'll see if I can add some extra fvwm3 configuration to change focus type for just Steam windows, I guess.
Actually this appears to have nothing to do with fvwm3 focus configuration. I'm now using:
Style * ClickToFocus
temporarily, and the Steam client menus still close the moment the mouse is moved off the menu label text. This happens even with moving the mouse to the right of the Help
menu label, i.e. it's not because the mouse is being moved down towards the Store
Library
Community
<my profile name>
'links' below the menu line.
Because of the issue I can't even tell you the exact Steam client version I'm using, as I can't get to the Help
> About Steam
item! I installed steam today, from scratch, using the Debian 12/bookworm steam-installer
provided steam
. It then downloaded the actual client, so presumably it's the latest.
To be 100% explicit, this appears to only be affecting that top line of menus: Steam
View
Friends
Games
Help
. The Store
Library
Community
<my profile name>
ones all work fine. The right click menu for a game in the Library listing also work. The menu opened from my profile name top-right (next to notifications) also works without issues.
Aha! Big Picture mode almost makes this usable as a workaround.
Now I could actually get at things like the system report and diagnostics I can confirm:
"runtime" : {
"version" : "0.20240610.91380",
I've now set up some key binds in fvwm3 to jump the mouse cursor by 24 pixels, which looks to be enough to get from Help
into the menu it pops up when clicked. But on doing that I still end up with the steam client acting on "moused over Community
" and it opens that menu.
Looking at this more precisely, the moment the mouse/focus leaves Menu
it closes its menu, I don't even need to have moved the mouse far enough down to be over Community
(or another entry on that line). It's simply that the moment focus is no longer on Help
its popup menu gets closed. I've made and uploaded a video to demonstrate this: https://www.youtube.com/watch?v=shLMtp7x7Hc
Basically these top-line menus need to:
Platform: Slackware64 14.0, Xorg 7.7, Xfce 4.10
Problem Description: With "Focus follows Mouse" option all menus and dropdown lists close automatically, when you move the mouse pointer out of it.
How to reproduce: Open "Settings" / "Window Manager" by executing /usr/bin/xfwm4-settings, Select "Focus Tab" and then "Focus follows mouse".
Possible cause: Steam seems to use the wrong X11 window type (top level window instead of pop-up menu window) to draw its menus, so the main Steam window loses focus when opening a menu. Additionally Steam closes the menu window as soon as the menu window loses its focus.
Other commercial applications like Opera and Google Chrome have no issues with their menus.
Why this needs to be fixed: Focus follows mouse is an accessibility option for impaired people.
Additional notes: Maybe this can be reproduced using the Windows version of Steam by going to Control Panel / Easy of Access Center / Make the mouse easier to use / Activate a window by hovering over it with the mouse.