Focus follows mouse option - focusing on underside windows

[oskar-gmerek]

Describe the bug When focus follows mouse is enabled, floated windows and 'windows' like launchpad or spotlight losing focus on behalf of windows assigned to the layout.

Applications: Floated windows, launchpad, spotlight and most other modals, popovers or overlays

To Reproduce Enable focus follows the mouse option. Open a few apps, and change the layout. Open for example launchpad, move the cursor over launchpad windows without clicking anything, and focus will be lost on behalf of the app assigned to the layout.

Expected behavior the cursor should not detect windows below the window it is on. Or in other words, it should not follow the sections of a layout if it is moved within the window above the stack.

Screenshots

1. Initial position of cursor

2. Cursor just moved (without any clicks)

Versions:

• macOS: 12.3.1
• Amethyst: 0.15.6

Debug Info

Version: 0.15.6 (93)

OS version: Version 12.3.1 (Build 21E258)

Screens:
    (0.0, 0.0, 2560.0, 1440.0) [(0.0, 0.0, 2560.0, 1440.0)]
    (2560.0, -304.0, 3200.0, 1800.0) [(2560.0, -56.0, 3200.0, 1800.0)]

Configuration:
floating: (
        {
        id = "com.apple.systempreferences";
        "window-titles" =         (
        );
    }
)
window-margins: 0
focus-follows-mouse: 1
mod2: (
    option,
    shift,
    control
)
enables-layout-hud-on-space-change: 1
float-small-windows: 1
screen-padding-bottom: 55
mouse-follows-focus: 0
mouse-swaps-windows: 1
screen-padding-right: 0
new-windows-to-main: 0
floating-is-blacklist: 1
mod1: (
    option,
    shift
)
debug-layout-info: 1
screen-padding-left: 0
window-minimum-width: 0
smart-window-margins: 1
follow-space-thrown-windows: 1
layouts: (
    tall,
    wide,
    fullscreen,
    column,
    "two-pane",
    "tall-right",
    "3column-left",
    "middle-wide",
    "3column-right",
    row,
    floating,
    "widescreen-tall",
    "widescreen-tall-right",
    bsp
)
mouse-resizes-windows: 1
window-margin-size: 10
enables-layout-hud: 1
window-minimum-height: 0
ignore-menu-bar: 0
use-canary-build: 0
restore-layouts-on-launch: 1
screen-padding-top: 0
window-resize-step: 30

[jd-solanki]

+1

[rsik]

Similar issue? Feels like there is a mouse vertical offset that affects hovering and swapping windows:

https://user-images.githubusercontent.com/26800931/169599599-f8e59250-3ad9-427a-b073-bcbe56b65a24.mov

[oskar-gmerek]

@rsik Yeah, I think it is related.

[csepulveda]

I got the same issue: If i disable the option focus follow mouse the issue its solved.

[oskar-gmerek]

@csepulveda

Solved is the mismatched word in that case. Nothing is resolved, and you are just disabling the affected option.

[michael-harvey-apto]

I noticed the same issue today, trying out the "focus follows" functionality for the first time. My configuration is tiled layout, focus follows mouse, and small dialogs (plus a few other windows) set to always float.

I am noticing the issue with small floating dialogs that disappear when I try to move the mouse over to them, AND with any windows set to always float. It does not happen to the Amethyst window, but I can reproduce reliably with the Notes Preferences window:

1. Set the layout to Tall
2. Open three apps, one of which is Notes
3. Open Notes preferences from the menu
4. Try to move the mouse to it. Observe that the tiled windows are raised one at a time to cover it. Even if you move directly from a tiled window to the floating window, it instantly raises the tiled window that is underneath it as if the floating window does not exist.
5. Clicking on Notes > Show All Windows in the dock shows it is still open, and I can bring it to the top that way, but still am unable to focus it.
6. Using Mission Control I can focus the window but as soon as I move the mouse it is covered up by whatever is underneath.
7. Using Shift-Option-J/K, I can cycle focus through the tiled windows but NOT the floating window. This is not an issue with the direction of cycling, no matter if I use C-O-J or C-O-K it always raises tiled windows in preference to floating windows and does not seem to see the floating windows at all.
8. Tried this with another app that is configured to "always float" in Amethyst, same behavior, so it is not a problem specific to small dialogs but to ANY floating window.

A workaround that almost works is to enable mouse-follows-focus: that will focus the keyboard at least, but as soon as you touch the mouse it gets covered up again, so still useless for configuration dialogs. Also it wont appeal to everyone (like me!) to have it turned on all the time, and a workaround shouldn't be necessary even if it did fix it. (It is also kind of jumpy, maybe mouse-follows-focus doesn't play nicely with focus-follows-mouse.)

Based on this I think the solution is:

1. Focus follows mouse needs to focus the window that is on top of the z order, so if you move from a tiled to a floating window it is the floating window that gets the focus not what is underneath it. REASON: This is the intuitive expectation.
2. When focus-follows-mouse is set, it is temporarily disabled when a floating window has the focus. As soon as you click outside the focused floating window, focus starts following the mouse again. If you focus back on the floating window, it is again suspended as long as that window has the focus. REASON: If a small dialog pops up in the center of the screen you can interact with it normally, without going through pain to try to find it and bring it to the top.
3. Fix Shift-Option-J/K so that it also focuses floating windows. REASON: Even if they disappear at least you'll be able get them back. Also, this is the intuitive expectation.

[maertsen]

3. Fix Shift-Option-J/K so that it also focuses floating windows. REASON: Even if they disappear at least you'll be able get them back. Also, this is the intuitive expectation.

This is #1069

[hannesrauhe]

As mentioned in the other issue: A solution would be to keep floating windows on top. That's what I'm used to from i3wm. The amethyst preference window does that but most other windows don't...