Menus broken with Focus follows mouse option.

[ghost]

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.

[ku1ik]

Same here. "Focus follows mouse" on.

[causal-agent]

I have the same issue as #64, running awesome with focus-follows-mouse.

[mmn80]

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 :)

[DarkStarSword]

There was also some discussion of a likely related issue on wmii: http://steamcommunity.com/app/221410/discussions/1/846938350833390522/

[DarkStarSword]

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.

[gdrewb-valve]

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.

[DarkStarSword]

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.

[gdrewb-valve]

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.

[mmn80]

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.

[ghost]

Confirmed, menus now seem to be working fine with focus-follows-mouse. Thanks!

[hvr]

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 :-(

[ghost]

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.

[conleymoorhous]

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.

[Carson365]

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."

[viggy96]

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.

[viggy96]

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.

[manen]

oh yeah. i've been experiencing this so long i thought it was a planned feature

[ryan-sg]

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.

[i92guboj]

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

[Athanasius]

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.

[Athanasius]

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.

[Athanasius]

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",

[Athanasius]

1. 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.

2. 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:

1. Have their popup open closer to them in vertical terms.
2. Not have a gap in the focus-following between the actual menu name and the popup. Focus should move smoothly between the two.