Hovering over things like items in the dock clicks on them

[arulagrawal]

I am having a weird issue where sometimes hovering over stuff like items in the dock or stuff in the menu at the top automatically clicks it without me doing anything but hovering.

I haven't been able to find what causes this issue, although restarting yabai fixes it.

The next time it happens I'll try to record it.

[koekeishiya]

Sounds like an issue with autofocus.

[koekeishiya]

Made some changes to master. I can no longer reproduce the issue.

[arulagrawal]

I am more confused now, I just restarted my laptop, and had the issue straight away

[ghost]

I have the same symptoms and so do other MacBooks.

These errors occur while certain apps are running(In my case, photo app is the problem.)
If you shut down the app or restart Yabai's service, the symptoms disappear.

However, symptoms recur at frequent intervals.

[arulagrawal]

I am having this issue even after compiling from the master branch. :(

[koekeishiya]

Still cant reproduce this in the latest release (v3.3.0).

[fiedl]

Hi, I came across the same issue. Can I somehow help to track this down?

▶ yabai --version
yabai-v3.3.4

▶ cat .yabairc
#!/usr/bin/env sh

# global settings
yabai -m config mouse_follows_focus          off
yabai -m config focus_follows_mouse          autofocus
yabai -m config window_placement             second_child
yabai -m config window_topmost               off
yabai -m config window_shadow                on
yabai -m config window_opacity               on
yabai -m config window_opacity_duration      0.0
yabai -m config active_window_opacity        1.0
yabai -m config normal_window_opacity        0.90
yabai -m config window_border                on
yabai -m config window_border_width          6
yabai -m config active_window_border_color   0xff775759
yabai -m config normal_window_border_color   0xff555555
yabai -m config insert_feedback_color        0xffd75f5f
yabai -m config split_ratio                  0.50
yabai -m config auto_balance                 off
yabai -m config mouse_modifier               fn
yabai -m config mouse_action1                move
yabai -m config mouse_action2                resize
yabai -m config mouse_drop_action            swap

# general space settings
yabai -m config layout                       bsp
yabai -m config top_padding                  36
yabai -m config bottom_padding               12
yabai -m config left_padding                 12
yabai -m config right_padding                12
yabai -m config window_gap                   16

echo "yabai configuration loaded.."

Environment:

• macOS Catalina 10.15.7
• three external displays
• MacBook Pro 15" mid 2014 with NVIDIA GeForce GT 750M 2 GB
• "Reduced motion" enabled in accessibility settings

I have prepared a screen recording, in which you can see:

• With yabai running, hovering dock icons will simulate clicking them, resulting in app being opened, which makes the dock pretty unusable at the moment.
• After stopping yabai, the dock works as usual.
• After starting yabai again, hovering dock icons continues simulating clicks.

[koekeishiya]

This should be resolved on master. See #660

[fiedl]

Thank you! I've just tried out master and everything looks good so far. I'll report back if the issue should reoccur.

Also thank you very much for this great project!

[fiedl]

Unfortunately, the issue has just reappeared. I've restarted the system in the meantime, and now the issue is back when using master.

▶ brew info yabai
koekeishiya/formulae/yabai: stable 3.3.4, HEAD
/usr/local/Cellar/yabai/HEAD-b6b495c (10 files, 705.4KB) *
  Built from source on 2020-11-23 at 19:44:08
From: https://github.com/koekeishiya/homebrew-formulae/blob/HEAD/yabai.rb

Please let me know if there is some way I can help to track this down.

Also, I was wondering whether something like #675 could be used to exclude the dock from focus_follows_mouse.

[dominiklohmann]

Also, I was wondering whether something like #675 could be used to exclude the dock from focus_follows_mouse.

#675 is about mouse_follows_focus, not focus_follows_mouse. They are entirely unrelated features.

On this bug: I've encountered this once recently after unplugging an external monitor, but have not been able to reproduce it reliably. Not sure what is happening here.

[midfm]

@dominiklohmann - I've found this can be inconsistent if there an application running that needs the discrete GPU (if you have one), in that case there is no GPU switch when the external monitor is unplugged.

For me, at least, this happens whenever there is a switch from discrete to integrated GPU. Switching back to the discrete GPU causes the phantom clicks to stop, without restarting Yabai. It's not just the Dock for me, either - clicks occur in Menu Bar menu items as well.

Edit: sorry I should add that I'm not yet using MASTER (I'm on 3.3,4), only giving my experience of the inconsistency I've noticed.

[fiedl]

• GPU switch: I've disabled the GPU switch this afternoon.
• External monitors: After waking my machine from sleep now, this issue has reoccurred. I did not disconnect my screens in between, i.e. they were connected before, during, and after sleep. However, I did turn off the screens during sleep. I'll try to reproduce this. Also, during the next sleep period, I'll check whether this also happens when I leave the screens in standby. Update: When keeping the monitors in standby, the issue does not occur after waking the machine from sleep.

The issue went away after a while without restarting yabai.

[koekeishiya]

Can you try to install version 3.2.0 as described in #660? According to some users reverting to that version also resolved this issue. The change made to master reverts a specific change that may have impacted this, and works the same way on the master branch as it did in v3.2.0. I am getting mixed reports here and I do not have the hardware to reproduce this bug on my system.

[fiedl]

Thanks! In the meantime, I've come up with reproducible steps:

1. Make sure auto GPU switching is disabled
2. Put system to sleep
3. Switch off external monitors
4. Wait until system has gone to sleep (fans turn off)
5. Press key on the keyboard to wake the system up again
6. Switch external monitors back on
7. Enter password to login
8. Move mouse onto the other external monitor (not the one with the login form)
9. Move the mouse down to the dock such that the dock will slide up
10. Hover over the dock icons

If the issue does occur, this will act like you've clicked on those icons rather than just hovering them.

I've tried this a couple of times to make sure it's reproducible. The issue does occur for me in:

• yabai v3.3.4
• yabai b6b495c

As you've suggested, I've installed yabai v3.2.0.

I can confirm that following above steps does not reproduce the error on v3.2.0.

However, I can't rule out that there might be something else going on, yet, because since reverting to v3.2.0, the focus-follows-mouse feature causes some flickering when the windows change their transparency due to the change of focus.

What also does confuse me:

The change made to master reverts a specific change that may have impacted this, and works the same way on the master branch as it did in v3.2.0.

For me, the issue did not occur on v3.2.0 so far, but does occur on master (b6b495c).

Please let me know if or when you have another candidate to try this on.

[koekeishiya]

Try to reproduce the issue using this commit: b1b4c0d
Expected result is no bug.

Then run from this commit: 0d3666e
Expect bug to be there.

[fiedl]

This is really strange: When makeing the project, the issue does not occur at all. When installing it with brew install --HEAD, it does occur.

Some details:

0d3666e

[2020-11-25 23:12:31] fiedl@fiedl-mbp ~/code
▶ git clone [email protected]:koekeishiya/yabai.git

[2020-11-25 23:12:56] fiedl@fiedl-mbp ~/code/yabai master
▶ git co 0d3666e

[2020-11-25 23:13:19] fiedl@fiedl-mbp ~/code/yabai 0d3666e
▶ make

[2020-11-25 23:17:23] fiedl@fiedl-mbp ~/code/yabai 0d3666e
▶ export PATH=$PATH:~/code/yabai/bin

[2020-11-25 23:17:49] fiedl@fiedl-mbp ~/code/yabai 0d3666e
▶ bin/yabai

Following the steps from above, the issue does not occur.

b1b4c0d

[2020-11-25 23:24:31] fiedl@fiedl-mbp ~/code/yabai 0d3666e
▶ killall yabai

[2020-11-25 23:25:17] fiedl@fiedl-mbp ~/code/yabai 0d3666e
▶ git co b1b4c0d

[2020-11-25 23:25:34] fiedl@fiedl-mbp ~/code/yabai b1b4c0d
▶ make

[2020-11-25 23:25:41] fiedl@fiedl-mbp ~/code/yabai b1b4c0d
▶ bin/yabai

Following the steps from above, the issue does not occur.

verify master

Verify that the issue is still reproducible on master (b6b495c).

[2020-11-25 23:29:01] fiedl@fiedl-mbp ~/code/yabai b1b4c0d
▶ killall yabai

[2020-11-25 23:29:03] fiedl@fiedl-mbp ~/code/yabai b1b4c0d
▶ git co b6b495c

[2020-11-25 23:30:04] fiedl@fiedl-mbp ~/code/yabai b6b495c
▶ make

[2020-11-25 23:30:13] fiedl@fiedl-mbp ~/code/yabai b6b495c
▶ bin/yabai

Following the steps from above, the issue does not occur, which is strange because it had failed before on master when installing it through brew install --HEAD.

verify brew install --HEAD

[2020-11-25 23:33:19] fiedl@fiedl-mbp ~/code/yabai b6b495c
▶ killall yabai

[2020-11-25 23:33:21] fiedl@fiedl-mbp ~/code/yabai b6b495c
▶ make clean

[2020-11-25 23:33:43] fiedl@fiedl-mbp
▶ brew install yabai --HEAD

[2020-11-25 23:38:56] fiedl@fiedl-mbp
▶ brew services start yabai

Following the steps from above, the issue does occur.

Is this really the same master?

2020-11-25 23:43:35] fiedl@fiedl-mbp ~/code/yabai b6b495c
▶ brew info yabai
koekeishiya/formulae/yabai: stable 3.3.4, HEAD
A tiling window manager for macOS based on binary space partitioning.
https://github.com/koekeishiya/yabai
/usr/local/Cellar/yabai/HEAD-b6b495c (10 files, 705.4KB) *
  Built from source on 2020-11-25 at 23:34:52
From: https://github.com/koekeishiya/homebrew-formulae/blob/HEAD/yabai.rb

So, this is b6b495c, too.

Next steps

I'll repeat the steps again in order to verify.

But do you have an idea in what the homebrew --HEAD version and the manual make version of master could be different in a way that would explain the issue? Could be the way yabai is started. I’ll also check whether there is a permissions issue, because when starting yabai manually, I think, the privacy settings etc. for the terminal may be used.

[dominiklohmann]

But do you have an idea in what the homebrew --HEAD version and the manual make version of master could be different in a way that would explain the issue? Could be the way yabai is started. I’ll also check whether there is a permissions issue, because when starting yabai manually, I think, the privacy settings etc. for the terminal may be used.

The homebrew formula uses make install over make to create a release build. If there's undefined behavior in the code somewhere, the optimizer may do unexpected things.

Might make sense to use sanitizers for this, but I'm not sure how feasible adding them is with how simple the Makefile is.

[koekeishiya]

The only commit between v3.2.0 and v3.3.4 that in any way affects window focus is this one:
ba36ce6

I haven't used asan and so forth in a while, but I doubt that is the issue in this case.
The code for focusing windows is not exactly huge; 10lines of code? I don't see anything undefined going on here.
https://github.com/koekeishiya/yabai/blob/master/src/window_manager.c#L833

I do however agree that there is an issue here, and it is from what I understand, related to machines that have a discrete graphics card. I still have not been able to reproduce the issue in any version of yabai on my end (I don't have a discrete graphics card).

[fiedl]

Back to square one: Today the issue did occur when I was running:

• b6b495c39 made with make
• b6b495c39 made with make install
• v3.2.0 (cc84266) made with make

These have previously been working for me.

So the issue is not in ba36ce6 as you have already suspected.

I'll report back if I find something new.

[jamesjlyons]

For what it's worth, I have yabai v3.3.6 running on two different laptops (both with discrete gpu) with Big Sur 11.1. I have this hover behavior only on one machine:

• 2018 15-inch MacBook Pro: Dock apps launch on hover. Restarting yabai temporarily fixes the problem sometimes.
• 2020 16-inch MacBook Pro: No problem with hovering over dock apps.

[fiedl]

I've added some debug output, originally to find out whether I could filter out the Dock window from the focus-follows-mouse feature. Thereby I found a couple of things:

1. If I'm not mistaken, the Dock window is not even managed by yabai's window manager, and therefore is not handled in EVENT_CALLBACK(EVENT_HANDLER_MOUSE_MOVED) in the first place. window is not present in this case.

2. I had my Finder configured to not show desktop icons (defaults write com.apple.finder CreateDesktop false). With this setting, when the issue occurs, e.g. when moving the mouse from one screen to the neighbouring screen, a lot of mouse events are recorded by yabai while moving the mouse over the desktop-wallpaper window on the second screen.

    EVENT_HANDLER_MOUSE_DOWN: 2571.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2571.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2652.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2652.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2736.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2736.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2803.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2803.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2839.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2839.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2870.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2870.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2889.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2889.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2909.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2909.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2916.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2916.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2920.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2920.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2920.00, 504.00
    EVENT_HANDLER_MOUSE_UP: 2920.00, 504.00
    EVENT_HANDLER_MOUSE_DOWN: 2902.00, 499.00
    EVENT_HANDLER_MOUSE_UP: 2902.00, 499.00
    EVENT_HANDLER_MOUSE_DOWN: 2867.00, 496.00
    EVENT_HANDLER_MOUSE_UP: 2867.00, 496.00
    EVENT_HANDLER_MOUSE_DOWN: 2851.00, 496.00
    EVENT_HANDLER_MOUSE_UP: 2851.00, 496.00
    EVENT_HANDLER_MOUSE_DOWN: 2851.00, 496.00
    EVENT_HANDLER_MOUSE_UP: 2851.00, 496.00
    EVENT_HANDLER_MOUSE_DOWN: 2865.00, 496.00
    EVENT_HANDLER_MOUSE_UP: 2865.00, 496.00
    EVENT_HANDLER_MOUSE_DOWN: 2900.00, 496.00
    EVENT_HANDLER_MOUSE_UP: 2900.00, 496.00
    EVENT_HANDLER_MOUSE_DOWN: 2938.00, 496.00
    EVENT_HANDLER_MOUSE_UP: 2938.00, 496.00
   

   • These mouse events are not only recorded when moving over the Dock, but they are recorded when moving over the entire wallpaper.
   • When resting the mouse cursor still, no mouse-down or mouse-up events are created.
   • When resuming mouse movement, again, mouse events are created.
   • When moving back to the previous screen, the mouse events stop.
   • When moving back to the second screen, the mouse events continue.
   • Note: A EVENT_HANDLER_DISPLAY_CHANGED event is not triggered in this scenario.
   • When moving the mouse over a window on that second screen, the mouse events stop.
   • When moving the mouse back to the wallpaper, the mouse events do not continue.
   • But when closing the window, i.e. the wallpaper is the only remaining window, moving the mouse over the wallpaper continues the mouse-down and mouse-up events.

3. In the case of defaults write com.apple.finder CreateDesktop true, when moving the mouse from one screen to another, there are still mouse events, but only a few, right after moving to the second screen.

    EVENT_HANDLER_DISPLAY_CHANGED: 750921484 12
    EVENT_HANDLER_MOUSE_DOWN: 2896.00, 952.00
    EVENT_HANDLER_MOUSE_DOWN: 3014.00, 952.00
    EVENT_HANDLER_MOUSE_UP: 3014.00, 952.00
    EVENT_HANDLER_MOUSE_DOWN: 3099.00, 952.00
    EVENT_HANDLER_MOUSE_UP: 3099.00, 952.00
    EVENT_HANDLER_MOUSE_DOWN: 3155.00, 952.00
    EVENT_HANDLER_MOUSE_UP: 3155.00, 952.00
    EVENT_HANDLER_MOUSE_DOWN: 3186.00, 952.00
    EVENT_HANDLER_MOUSE_UP: 3186.00, 952.00
    EVENT_HANDLER_MOUSE_DOWN: 3192.00, 952.00
    EVENT_HANDLER_MOUSE_UP: 3192.00, 952.00
    EVENT_HANDLER_MOUSE_DOWN: 3194.00, 952.00
    EVENT_HANDLER_MOUSE_UP: 3194.00, 952.00
    EVENT_HANDLER_MOUSE_DOWN: 3195.00, 952.00
   

After that, the mouse events stop, even when continuously moving the mouse over the wallpaper.

If one is fast enough and moves the mouse cursor right over the Dock while these events are triggered, some Dock icons will receive clicks. If one waits a second or so until the events are over, one can hover over the Dock without Dock icons receiving click events.

Can we somehow find out what triggers these mouse events?

For now, I'm leaving the setting at defaults write com.apple.finder CreateDesktop true and will report back if the issue should reoccur with this setting.

[koekeishiya]

The mouse-down and up events are generated by yabai because the only way to switch focus to another display (that has no window) is to synthesize a click on the desktop itself. Setting the CreateDesktop variable to false apparently breaks this and likely other things: https://github.com/koekeishiya/yabai/blob/master/src/display_manager.c#L314

There is no other way of focusing a display with no windows and I will not remove this because some people have set an undocumented Finder property.

[fiedl]

The mouse-down and up events are generated by yabai because the only way to switch focus to another display (that has no window) is to synthesize a click on the desktop itself.

Thank you! 🎉 — So, I would imagine if that does not have the expected effect of focusing the second display, the window manager just keeps clicking, which would explain the observed behaviour.

I will not remove this because some people have set an undocumented Finder property.

I'm perfectly happy having found out the cause of this problem and just leaving CreateDesktop set to true.

I really appreciate your work on yabai!

[pleappleappleap]

I am running Yabai 5.0.2 and I'm still experiencing this problem. I am on a MacBook Pro 16" M1 on Ventura 13.1. Restarting the Yabai service doesn't fix it.

Any ideas? Frankly the only feature I use is focus-follows-mouse, so this is a bit of a dealbreaker for me.

[paulodiovani]

I'm having this same issue too,

• It happens only if the desktop is visible, not if there are windows
• it happens regardless of which monitor (main or extended)

I would rather yabai didn't click on the desktop to focus at all.

[koekeishiya]

Made improvements on master. See this comment though.. #863 (comment)

[paulodiovani]

The issue still happens to me.

yabai-v7.1.0

[sasha-id]

same, yabai-v7.1.1