Accidental mouse hover sometimes causes wrong window to be focused

[alt-tab-macos-bot]

This issue was opened by a bot after a user submitted feedback through the in-app form.

From: [email protected]

Message:

I really like having the ability to select windows using the mouse, but having it select on hover is much less useful than select on click.

It's very easy to accidentally select windows when using Alt+Tab if the mouse is already somewhere in the center of the screen (which is quite often).

I propose switching the mouse behavior to be on click instead of on hover, or to add another option (which I know you're trying to avoid)

Debug profile

• App version: 3.17.0
• App preferences:
  • NSStatusItem Preferred Position Item-0: 826.5
  • NSWindow Frame com.sindresorhus.Preferences.FrameAutosaveName: 2051 714 549 502 0 0 3440 1417
  • SUAutomaticallyUpdate: 0
  • SUEnableAutomaticChecks: 0
  • SUHasLaunchedBefore: 1
  • SULastCheckTime: 2020-04-26 15:52:14 +0000
  • arrowKeysEnabled: true
  • cancelShortcut: ⎋
  • closeWindowShortcut: W
  • hideShowAppShortcut: H
  • holdShortcut: ⌘
  • minDeminWindowShortcut: M
  • mouseHoverEnabled: true
  • nextWindowShortcut: ⇥
  • preferencesVersion: 3.17.0
  • previousWindowShortcut: ⇧⇥
  • quitAppShortcut: Q
  • showMinimizedWindows: false
  • spacesToShow: 0
• Applications count: 64
• Windows: 17
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 4, spaceIndex: 2}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: true, spaceId: 4, spaceIndex: 2}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 4, spaceIndex: 2}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 5, spaceIndex: 3}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 5, spaceIndex: 3}
  • {isMinimized: true, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: true, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: true, isHidden: false, isOnAllSpaces: false, spaceId: 4, spaceIndex: 2}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 1, spaceIndex: 1}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 4, spaceIndex: 2}
  • {isMinimized: false, isHidden: false, isOnAllSpaces: false, spaceId: 4, spaceIndex: 2}
• OS version: Version 10.15.4 (Build 19E287)
• OS architecture: x86_64
• Locale: en_US (current)
• Spaces count: 5
• Dark mode: Dark
• "Displays have separate Spaces": unchecked
• Hardware model: MacBookPro16,1
• Screens count: 1
  • (0.0, 0.0, 3440.0, 1440.0)
• CPU model: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
• Memory size: 34.36 GB
• Active CPU count: 16
• Current CPU frequency: 2.4 Ghz
• Resource utilization:
  • CPU: 2.8%
  • Memory: 101M+
  • Threads count: 9

[nathang21]

Update: I just realized disabling the "Select on hover" option does exactly this! I thought it exclude the mouse altogether.

Feel free to close this.

[lwouis]

Adding to that, @mfn made the very interesting observation that HyperSwitch has some kind of subtle anti-accidental interaction UX going on.

I'll keep this ticket open to remember to revisit this, and experiment. When I was working on #259 recently, I noticed that macOS also by default disables mouse hover on scrolling, until you start moving the mouse again.

Some kind of anti-accidental interaction mechanism seems appealing, on top of the existing on/off switch.

[lwouis]

I implemented this ticket. It turned out to be way more complex than I thought (as usual with this project). Some implementation notes:

I implemented 35px of threshold before activating mouse hover over the windows. The 35px are traveled within the whole view, that includes from the outer padding. This supports these 2 scenarios:

• User has their pointer already where AltTab UI is going to appear. When it appears, the first 35px of mouse travel will be ignored, then it starts selecting thumbnails

• User has their pointer outside where AltTab UI is going to appear. When it appears, they can move the mouse as much as they want outside AltTab UI. As soon as they enter it though, it counts 35px within it, then activates mouse hover.

Once the 35px are reached, the mouse hover is activated until the UI is dismissed then brought back again.

Some limitations:

• When the pointer is outside where AltTab UI is going to appear, it could be argued that we should count the 35px here too, as they indicate user activity. That being said, this is arguable. Also because there are 18px of padding before the user reaches a thumbnail in AltTab UI, there are only 17 "unresponsive" pixels that such user would go through before they get their mouse hover to work. I think in practice it's really small.

• Using distance to mitigate false input doesn't help with quick motion. If the user is making a big mouse movement, 35px are instantly traveled, and the mitigation fails. I think that in addition or in replacement with distance, a time-based mitigation may be useful. However, time is really impacting the UX as someone who actually want to mouse hover will feel their action are delayed by this arbitrary timeout, and could think that AltTab UI is unresponsive when just summoned. At least with distance-based mitigation, a quick user can just move around and get very quick access to mouse hover interaction.

• For distance-based, another thing that can be used to guess user intent is look at momentum: has the mouse been accelerating or decelerating since the UI appeared, was there a stop, etc. See this project for instance. I thought about it and without some actual data from real users and some ML, I don't see clear patterns to implement to would be highly likely to indicate a false positive.

I feel it's tempting to implement both and add a new preference like "ignore accidental mouse movement" but there are so many issue doing this: preferences complexity, how to explain clearly to the user how the mitigation works, etc.

I would be very interested to hear from you guys. As of now, I think I will not release that work. I'm not convinced it is actually an improvement.

[RoadToDream]

After going through the comments, I understand now that why this feature hasn't implemented. The distance based method seems not to be a good idea, my initial idea is not a proper one.
May we borrow the idea from Windows? Mouse hover is just "hover", it will not activate the window under the cursor but just highlight the thumbnail. To activate the window under cursor, user needs to click on it.

[lwouis]

@RoadToDream That's an interesting idea. We would replace the checkbox here:

By a dropdown menu with 3 options:

• Mouse hover
• Mouse click
• Ignore mouse

For the second option, we could have another visual clue for hovering that is distinct from selecting the window, like Windows does. Sounds good to me, although it's yet another preference instead of some smarter strategy that could be turned on for everyone. That being said, maybe such a strategy simply doesn't exist, so this would be an improvement in the meantime.

[RoadToDream]

@RoadToDream That's an interesting idea. We would replace the checkbox here:

By a dropdown menu with 3 options:

• Mouse hover
• Mouse click
• Ignore mouse

For the second option, we could have another visual clue for hovering that is distinct from selecting the window, like Windows does. Sounds good to me, although it's yet another preference instead of some smarter strategy that could be turned on for everyone. That being said, maybe such a strategy simply doesn't exist, so this would be an improvement in the meantime.

I think a dropdown menu is a good idea. Just disable mouse hover works fine for me currently, and if border appears when mouse hover on it(when mouse hover to select window is disabled), it should feel better.

[Jack-Bristow]

So I've found this issue from #1617, I think for users that are very keyboard-centric and only use AltTab by cycling through windows via repeated tab key presses, it is definitely worth implementing the option to completely ignore all interactions with the mouse (movements & clicks). For this type of user, this would have the added benefit of still being able to drag & drop files between windows, without dropping the file onto the AltTab window preview itself. This would also helpfully fix the bug mentioned in #1617.

Video demonstrating an example workflow:
https://user-images.githubusercontent.com/6740305/173241930-c44917e0-bb0b-47cd-ad93-a9e915e0143e.mov

As you can see from the above video, I can avoid the aforementioned bug by making sure my cursor is out of the way where the window previews would appear, meaning my mouse does not have a chance to interact with them. Most of the time I forget to do this and instead have my mouse in the centre of my screen, where it will select a random window.

[lwouis]

@Jack-Bristow #1617 doesn't discuss a bug, but a feature request. AltTab is working correctly, not dysfunctioning.

I'm a bit struggling to understand your proposal. This ticket here is about finding a way to avoid accidental mouse hover. What is your proposal for that?

[Jack-Bristow]

What I meant by my comment was that in AltTab's preferences, if you disable everything relating to mouse options, you would expect the interface to not have any reaction to the mouse - whether that be by mouse hover, clicking or dragging a file. I was suggesting that the previous comment of implementing some sort of option to ignore mouse, would disable this feature of dragging a file onto a window preview.

Perhaps under the "Controls" tab in AltTab's preferences, there could be a sub section called Mouse Options or something similar, that controls how the mouse reacts when the window switcher is open. Some sort of master control that enables/disables all mouse control would make sense at the top of this sub section, with all other mouse options (mouse hover changes selection/clicking focuses window/drag & drop file onto window) being greyed out/un-selectable if mouse control is disabled.

I hope this clears up my previous comment.

[lwouis]

I realize now that moving focus with mouse hover is probably not a good idea. Mouse hover should probably show which preview is hovered (see #2078) so that it's clear which window would be focused if the user clicks, or drop from a drag-and-drop.

I'll close this ticket as it's now subsumed by #2078.