Window appears unexpectedly when "Hide Dock icon and detect notch clicks" is turned on.
Closed this issue · 13 comments
When "Hide Dock icon and detect notch clicks" is turned on the settings window appears if I move the cursor under the notch.
When "Hide Dock icon and detect notch clicks" is disabled the window only appears if I click in the notch.
This appears to be new behavior with 1.0.4. M2 MacBook Air, no external screen.
Sounds like there might be some messed up settings. Try this: hold down the option key while clicking on the help (?) icon. You'll see a new button appear that opens a popover. Click on "Reset to Defaults" in that window, then restart the app.
Hm, nope. Did the reset and saw my settings revert. Same behavior. (This time also with a secondary monitor attached, if that's relevant.). Tried it with the fake notch with the same behavior.
I have exactly the same Mac and screen configuration, and can't reproduce this issue. Is there another app running that detect clicks under the notch.
I got nothin' otherwise.
I'm seeing the same bug on my M2 MacBook Air running Ventura 13.4 (22F66). With the "Hide Dock icon and detect notch clicks" button enabled, every time my mouse cursor enters the notch, the Notchmeister window steals focus and comes to the foreground. The window steals focus regardless of whether it was closed or just moved behind other windows.
I've done the reset without any improvement. I quit Bartender, which I thought might have been causing the problem, but that didn't help. I then quit every app that lived in the task bar, thinking one of them might have been causing a problem. Again, the problem remained.
Oh! I thought I responded to this. It appears that Moom is the cause of the incompatibility on my machine. Quit Moom and Notchmeister works as expected.
Yeah, that fixed it. Unfortunately, Moom is a must-have app for me. It's too bad they can't work together.
You can get Moom and Notchmeister to work properly if you disable the "Pop up controls when hovering over a Zoom button" option.
I just reached out to the Moom developers. Will update this thread as we get more info. Thanks for the tip!
Hi, this is one of the aforementioned Moom developers. Thanks for bringing us into the loop!
I'm pretty sure I could work around this on our end by making Moom ignore the "NotchWindow 1 - Child (Activation)" window that triggers this, but if you don't mind, I'd love to figure out what's actually happening here, instead of just using the ignore hammer.
In that spirit, here's where I'm at: It seems Notchmeister's settings window is triggered as soon as Moom tries to determine the accessibility element under the mouse pointer via AXUIElementCopyElementAtPosition() while the mouse hovers the aforementioned "NotchWindow 1 - Child (Activation)" window, with code along these lines:
CGPoint location; // assume this is the current mouse location
AXUIElementRef systemUIElement = AXUIElementCreateSystemWide();
AXUIElementRef locationUIElement = NULL;
AXUIElementCopyElementAtPosition(systemUIElement, location.x, location.y, &locationUIElement); // => Notchmeister settings window appears
There's no AXPress or similar, it's the mere AXUIElementCopyElementAtPosition() call that causes this. You can confirm this by trying to inspect the notch window with Accessibility Inspector while Moom is not running. If your Mac is like mine, you'll find that the same thing happens — the settings window appears.
Seeing as the issue seems to hinge on Notchmeister's notch click detection, one possible explanation is that somehow, AXUIElementCopyElementAtPosition() seems to get misinterpreted as a click. I have no idea why that happens, though. Could it have to do with how Notchmeister detects those clicks?
Update: silly me. I was so tired last night, I didn't realize I was on GitHub, which means I can look at Notchmeister's source code!
So I checked just now, and my "how Notchmeister detects those clicks" suspicion led me straight to ActivationView and specifically, a misuse (IMHO) of hitTest() — see the pull request.
Nice catch, @petermaurer !
Thanks @petermaurer - I just merged the change and it will be in the next release.
I pushed out a new TestFlight build with the fix this morning (https://testflight.apple.com/join/pIGViV74). Let me know if there are any issues. Thanks!
Works great!