Menus broken with Focus follows mouse option. #6

ghost opened this Issue Dec 20, 2012 · 36 comments


None yet

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.


Same here. "Focus follows mouse" on.

@gdrewb-valve gdrewb-valve was assigned Dec 20, 2012

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 ~= "Steam" then
            client.focus = c

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:


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.

@triage-valve triage-valve was assigned Jan 9, 2013

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!

hvr commented Jan 9, 2013

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.


@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).


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.


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.

  • Moving mouse onto a dropdown menu (for example, STORE) draws the menu.
  • Moving mouse anywhere causes the menu to vanish. To clarify:
    • Move mouse 1+ pixels in any direction on the word STORE, menu disappears.
    • Move mouse onto menu below STORE, it disappears before you can use it.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment