`mouse_follows_focus` improvement suggestions

[chandlerc]

Hello folks, still loving Yabai. =D

I've had to re-enable SIP and so I'm learning how to work with that. One of the biggest helps for me is mouse-follows-focus. Without this, using yabai to change which external display is focused doesn't work. But if I use mouse-follows-focus along with focus-follows-mouse, it works great.

However, this has caused me to care a lot about mouse-follows-focus. I have one specific issues that causes me ... a lot of difficulty: focusing Finder when my mouse moves over the gap around windows. This is especially true when moving to the menubar. With focus-follows-mouse this isn't too bad. But with mouse-follows-focus, the mouse can be snapped to the center of the window when it drifts over the border. This is very surprising, and compounds issues.

I thought of a few improvements that would really help me, and wonder if they would be feasible.

1. Avoid changing focus when the mouse is over the desktop. I guess this is properly about focus-follows-mouse, but thought I'd mention it.
2. Avoid focus change (in any direction) when the mouse is within the padding of the window. The goal would be both to avoid de-focusing the window, but as or more important to not re-focus it and center the mouse within the window.
3. Maybe even more awesome than (2) would be to remember the location of the mouse within a window when it loses focus and rather than snapping to the center of the window, snap to previous location of the mouse within the window. This would be amazing for me as it would let me leave my mouse in a predictable place (maybe a button) and it still be there even after switching windows.
   • Maybe a combination of (2) and (3) would be even better. When focusing a window due to focus-follows-mouse, don't change the mouse position at all. Only do mouse-follows-focus when the focusing event isn't due to following the mouse. And then do (3). This would let you move the mouse out of a window and back, and it would never snap to a different location. But when switching focus through key bindings or some non-mouse event, can restore the previous mouse location within the window.

What do you think?

Also happy to provide any more details useful.

[koekeishiya]

Without this, using yabai to change which external display is focused doesn't work.

Uh, are you sure about this one? If so, that is definitely a bug; yabai -m display --focus <..> should work with SIP enabled.

focusing Finder when my mouse moves over the gap around windows. This is especially true when moving to the menubar.

I agree this is annoying. My "solution" so far has been to hold down the mouse_mod modifier to temporarily disable focus follows mouse while reaching for the menubar. This is not exactly optimal and I am open to suggestions.

But with mouse-follows-focus, the mouse can be snapped to the center of the window when it drifts over the border. This is very surprising, and compounds issues.

So if I understand correctly, when focus is changed because of focus follows mouse, it will incorrectly trigger mouse follows focus, causing a sort of looping effect. I did try to implement some measure against this, as this is stupid, but apparently it does not work in all cases. I consider this a bug as well, and will try to look into a different way of solving that.

Avoid changing focus when the mouse is over the desktop. I guess this is properly about focus-follows-mouse, but thought I'd mention it.

I think it makes sense that the desktop should not be focusable, but I am not sure how feasible this is. Will have to investigate.

Maybe even more awesome than (2) would be to remember the location of the mouse within a window when it loses focus and rather than snapping to the center of the window, snap to previous location of the mouse within the window.

This seems like an interesting idea that I will likely test locally to see what it feels like.

When focusing a window due to focus-follows-mouse, don't change the mouse position at all. Only do mouse-follows-focus when the focusing event isn't due to following the mouse.

This is definitely the expected behaviour and the way it should work, for sure.

[chandlerc]

Without this, using yabai to change which external display is focused doesn't work.

Uh, are you sure about this one? If so, that is definitely a bug; yabai -m display --focus <..> should work with SIP enabled.

Sorry, it works, but not quite completely. I filed #1020 for this with the full details.

[tariqc80]

focusing Finder when my mouse moves over the gap around windows. This is especially true when moving to the menubar.

other window managers solve this issue by adding a delay to the time it takes for the focus to switch. There are several issues open with this request. #936, #509 One of these was closed because I don't think the reason for this feature was explained correctly.

@koekeishiya please take a look at my comment just recently added to that issue, it would be great to get this in at somepoint. https://github.com/koekeishiya/yabai/issues/509#issuecomment-946336128

[koekeishiya]

other window managers solve this issue by adding a delay to the time it takes for the focus to switch. There are several issues open with this request. #936, #509 One of these was closed because I don't think the reason for this feature was explained correctly.

@koekeishiya please take a look at my comment just recently added to that issue, it would be great to get this in at somepoint. #509 (comment)

https://github.com/koekeishiya/yabai/issues/509#issuecomment-953687912

-- Pasting the reply here as the other issue is closed.

---

if we lose focus, the popup will close

Some improvements have been made for this in the-future branch, which will be released later this year. See https://github.com/koekeishiya/yabai/issues/407#issuecomment-759605800

Hmmm, this is a pretty important feature for those that use focus follows mouse. I wonder if there's another work around that others use?

The current workaround in yabai is to press and hold the modifier defined as yabai -m config mouse_modifier .. while moving across applications, or up to the menubar. focus-follows-mouse is temporarily suspended while this modifier is pressed.

The issues is this, occasionally it's necessary to drag the pointer across a field without losing focus. For example, navigating to a hover popup window, or navigating to the menu bar when another window is in the way; if we lose focus, the popup will close, or the menu bar context will switch.

My reasoning for the modifier-workaround instead of adding a general delay to the focus switch, is that in the majority of cases I want instantaneous switching upon hover. The "move to menubar" or "reach beyond a window" is the rare case for me, in which holding a modifier key is not a big deal.

It is not particularly trivial to implement focus-on-delay with the current implementation in yabai. I can't just extend the current version, due to how the current event-system works. It would be hack-ish at best, if not re-imagined and rewritten.

[chandlerc]

The issues is this, occasionally it's necessary to drag the pointer across a field without losing focus. For example, navigating to a hover popup window, or navigating to the menu bar when another window is in the way; if we lose focus, the popup will close, or the menu bar context will switch.

My reasoning for the modifier-workaround instead of adding a general delay to the focus switch, is that in the majority of cases I want instantaneous switching upon hover. The "move to menubar" or "reach beyond a window" is the rare case for me, in which holding a modifier key is not a big deal.

It is not particularly trivial to implement focus-on-delay with the current implementation in yabai. I can't just extend the current version, due to how the current event-system works. It would be hack-ish at best, if not re-imagined and rewritten.

FWIW, I'm not a fan of the delay approach either for similar reasons.

I do find it hard to remember to use the modifier, and by the time I remember, usually the damage is done, so I'm interested in finding better options. But using a delay seems less good.

I'm much more interested in options based around analyzing where the mouse is and using that as an additional signal to the modifier override.

Sorry I've not had time to get back to this issue w/ more experiments and maybe even some GIFs showing the issue or instructions to reproduce, just been really busy recently. crossing my fingers for this weekend, we'll see.

[tariqc80]

The modifier approach offers a degraded user experience. I would mark the focus follows mouse feature as broken given it's current UX. I shouldn't need two hands to navigate a GUI. Every other WM with a ffm implementation has a configurable delay.

My reasoning for the modifier-workaround instead of adding a general delay to the focus switch, is that in the majority of cases I want instantaneous switching upon hover. The "move to menubar" or "reach beyond a window" is the rare case for me, in which holding a modifier key is not a big deal.

The delay is typically around 40ms - 80ms; it's barely noticeable, yet enough time to get your mouse from the window to the title bar. Also this activation bug happens in contextual windows within the active window too, as you can see in my screen recording of zoom here: https://github.com/koekeishiya/yabai/issues/509#issuecomment-946336128

I understand that it might not be a trivial improvement to add a delay, but it sounds like either delay or auto detection approach would require the same lift to extend the logic. Once extended it's very trivial to add a delay, and the improvement to the UX would be dramatically increased. In contrast, the auto detection implementation would require more complex logic and possibly add a set of new quirky behaviors.

It would be a configurable delay, that you can turn off if you don't want it.

[typkrft]

The modifier approach offers a degraded user experience. I would mark the focus follows mouse feature as broken given it's current UX. I shouldn't need two hands to navigate a GUI. Every other WM with a ffm implementation has a configurable delay.

My reasoning for the modifier-workaround instead of adding a general delay to the focus switch, is that in the majority of cases I want instantaneous switching upon hover. The "move to menubar" or "reach beyond a window" is the rare case for me, in which holding a modifier key is not a big deal.

The delay is typically around 40ms - 80ms; it's barely noticeable, yet enough time to get your mouse from the window to the title bar. Also this activation bug happens in contextual windows within the active window too, as you can see in my screen recording of zoom here: #509 (comment)

I understand that it might not be a trivial improvement to add a delay, but it sounds like either delay or auto detection approach would require the same lift to extend the logic. Once extended it's very trivial to add a delay, and the improvement to the UX would be dramatically increased. In contrast, the auto detection implementation would require more complex logic and possibly add a set of new quirky behaviors.

It would be a configurable delay, that you can turn off if you don't want it.

You can turn off FFM in yabai and use https://github.com/sbmpost/AutoRaise instead if the current iteration isn't working to your liking. It has a configurable delay.

[tariqc80]

You can turn off FFM in yabai and use https://github.com/sbmpost/AutoRaise instead if the current iteration isn't working to your liking. It has a configurable delay.

@typkrft yup, that's exactly what I do now, and the UX in autoraise is much better.

As a user of Yabai, I'm advocating for this feature so I don't have to run a separate application.

[koekeishiya]

The modifier approach offers a degraded user experience. I would mark the focus follows mouse feature as broken given it's current UX. I shouldn't need two hands to navigate a GUI.

I very much agree with this sentiment, and if adding a delay was trivial I would do that. The reason it is not trivial is that we do not actually poll the mouse-state like most other (on macOS anyway) solutions do.

Instead we react to a "your mouse moved" event that macOS sends us. When no movement occurs, no code is running, so there is no way to track how long you've been waiting.

This can be solved of course, but it involves running some code to track this on a separate thread, this thread then needs to be able to spin off new or even cancel out the focusing event. Then inside all of this we need to handle thread synchronization and what not.

With a polling system (check the mouse-state every x milliseconds or whatever) many of these issues go away.

I'm not particularly interested in going into a deep discussion regarding this now, as I mentioned, these problems can obviously be solved given some time, but it's not really on my list of priorities for things to look into. My point is that it isn't something I can just do in an hour during lunch.

[Hoss3770]

Any news on the delay feature? Is it now maybe ready to be added :) ?