GNOME Bugzilla – Bug 609722
alt-tab refuses to focus on initial item for 500ms if initial item not focussed
Last modified: 2021-07-05 14:46:05 UTC
Created attachment 153603 [details] [review] Patch to allow switching to deselected item early if mouse pointer wiggled How to reproduce: - Start up firefox, a terminal, and rhythmbox, and emacs (exactly four applications) - Open-up the alt-tab switcher while the application that appears to the center-left of the app-switcher is selected, but have the mouse pointer just slightly to the right of the center of the screen. Wiggle the mouse pointer. Expected result: - app switcher should switch to the center right application, Actual result: - For 500 ms, the app switcher won't switch to this application What I'm describing probably sounds nitpicky, but the behaviour is actually really frustrating for me. It's obviously not right to switch right away to an unselected application, but if you move the mouse, it's a strong indication that you want to switch applications in alt-tab with the mouse. MacOS X works how I describe, why can't Gnome Shell? (with the patch I'm about to attach, it can!) Not sure if the patch I attached is really optimal in terms of coding style. Happy to edit it if things need changing.
I am pretty certain this behavior was intentional. IIRC, the argument was that the user might be moving the mouse to the new window at the same time as they are typing Alt-Tab, and might cross through the switcher window in the course of doing that, and so mouse activation should only be enabled if the user seems to not be typing (eg 500ms goes by without a keystroke)
Hmm, not sure what to say to this design being intentional. I haven't done any exhaustive studies, but from my own experience I don't mouse over to the new window until I've switched to it. If a window was visible, why would I use alt-tab to switch to it while mousing over? I'd just as soon click on the window and be done with it. Again, I'd point out that MacOS X behaves the way I describe (select application after some *actual* mouse motion has been registered) which I feel is some indication I'm not totally crazy here. Are you sure you're not confusing this with the design decision not to immediately switch to the window under the mouse when alt-tab is opened? That makes sense to me (and is, again, the way MacOS X behaves). I'm definitely not talking about reverting that behaviour, just amending it with an (IMO sensible) exception.
(In reply to comment #2) > Are you sure you're not confusing this with the design decision not to > immediately switch to the window under the mouse when alt-tab is opened? Yup. The first version of the code had just that rule, and the designers said we should change it to the current version.
What feels even odder than to me than the 500ms timeout on enter/leave is the fact that a pure wiggle (no enter and leave) never selects the item. [ For Metacity in focus-follows-mouse mode I recently implemented the rule that if the window under the pointer mismatches the focus (because you alt-Tab'ed away from it, say), you can move the mouse a bit and get the focus back there, because of customer complaints about having to leave and reenter. And in general I think wiggling the mouse should be treated as an intent to make the mouse win in a mouse-vs-keyboard situation. ] And to me, if you move the mouse while simultaneously hitting alt-Tab, that's a clear indication that you are planning to select in the Alt-Tab with the mouse, I can't really imagine moving the mouse to do something *else* while Alt-Tab'ing. Not until we get dual-core brains. So, let's wait for design input, but I'm definitely on the side of changing this... the current behavior just doesn't make sense to me.
So, as the patch is now it isn't what we want. I don't want accidental or incidental mouse motion to interfere with the keyboard navigation. That was the reason we had the delay in there. That said, I agree we do have a problem when the mouse is already in position and it isn't possible to immediately select the item beneath the pointer. Maybe, as I think Owen suggests, we need to be a little smarter about the type of mouse motion we ignore. A "wiggle" is pretty clearly an intentional gesture and should probably set the focus. Or maybe the problem is mostly a special case of the initial display of the switcher? Perhaps the initial display can use different rules than when one is actively using keynav?
The patch wouldn't be very difficult to update to support handling a wiggle. It already measures a movement delta for mouse motion, and only overrides the timeout if a certain amount of motion (set arbitrarily at 5 pixels) has been registered. Adding a conditional to register a certain amount of movement in at least two opposite directions would be fairly trivial, though I'd humbly suggest that the behaviour already implemented captures the spirit of your requirements.
Review of attachment 153603 [details] [review]: marking needs-work per discussion
Do you intend to update the patch, William?
(In reply to comment #8) > Do you intend to update the patch, William? Wow, I'd totally forgotten about this issue. To be honest it doesn't frustrate me anymore -- at the time I had filed it, I had just switched back to using Linux/GNOME after a stint of using the Mac for several years. My guess is that I've just gotten used to the current behaviour. I suspect me compiling/hacking on Gnome Shell would be difficult with my current setup (Ubuntu 13.04), so for now I'll just leave it to someone else to fix my patch / this bug, if they think it's worth doing. :) I imagine the patch below has bitrotted quite a bit in 2 1/2 years...
Unmarking this NEEDINFO.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.