When drawing a mouse gesture and using any action affecting the "window under cursor", the window is not identified correctly when the finishing point of the gesture is inside the drawing area.
E.g.: When drawing a gesture to minimize a window, the window is only minimized when the finishing point of the gesture is (A) in the desired windows and (B) outside the drawing area. If the gesture ends within the drawing area, the action to minimize the window (or whatever else) is applied to BTT itself since in this case the window under the cursor is a BTT window.
Desired behaviour: Ignore the BTT drawing area window and apply action to "real" window under cursor.
Affected system: Apple Macbooc Air M1, macOS Ventura 13.3.1
having same issue and posted about it. none of the 'under cursors' are working, quit or minimize. tried work arounds ie send shortcut to app but noe work. Only hide all windows works
okay cool. thanks for the quick response. just wanted to make sure I wasnt going crazy lol and it wasnt working anymore. look forward to it and thanks again!
Im having issue minimizing under cursor only with Adobe Apps. I'm using the three fingers down on a Magic Mouse 2 on M2 MacBook Pro 16" MacOS Ventura 13.4.1
On a side note, I'm also having to restart BTT sometimes when scrolling no longer works, it fixes itself after BTT restart.
mhm opt+middle click should be unrelated to the issue discussed above. For drawing gestures the problem was that their overlay was recognized as the "window under cursor", causing the issue.
I just tried it, but it seems to work fine here (at least with the apps I'm using, including Safari). Is your BTT enabled in System Settings => Privacy & Security => Accessibility?
that sounds very plausible, maybe they forgot to turn off the accessibility features of the overlay window they use to dim the screen. In that case BTT would see the HazeOver appâs window as window under cursor.
unfortunately if thatâs the case, it could only be fixed by HazeOver. You could verify with the conditional activation group âhovered ui elementâ viewer in BTT
Update: It is very dependent on precise location of cursor.
Please see attached video to watch this bug in action.
HazeOver is disabled and quit. BTT was just restarted. You can see each time I middle click because I also added "dim screen" (just as a way to show that I am clicking)
Are you possibly using floating webviews in BTT? There was a bugfix sometime after 4.504 related to hidden floating webviews that could influence this.
I can confirm the bug reported in this thread. The âActivate/Bring to Front Window Under Cursorâ action does not work when triggered by mouse gestures, but works perfectly when triggered by mouse buttons.
Action sequence:
Activate/Bring to Front Window Under Cursor
Send Keyboard Shortcut: âW
Goal: Close tabs/windows under cursor, even when theyâre in background/inactive
Results: With Mouse Gesture trigger:
⢠Does not work at all
⢠No window activation occurs
⢠The action appears to target BTTâs drawing overlay instead of the actual window beneath
⢠Ending the gesture outside the drawing area does NOT fix the issue With Middle Mouse Button trigger:
⢠Works flawlessly on all apps (Safari, Chrome, Finder, etc.)
⢠Reliably activates background windows
⢠Correctly closes tabs when available, otherwise closes the window
⢠No delay needed - instant and perfect behavior
System:
⢠macOS (current)
⢠BetterTouchTool (latest version)
⢠Logitech mouse via Logitech Options/G Hub
Expected Behavior: The gesture trigger should ignore BTTâs own drawing overlay window and apply the action to the actual window under the cursor, just like mouse button triggers do.
This limitation makes mouse gestures unusable for any âwindow under cursorâ actions, which is a shame since gestures feel more natural and visually appealing than button clicks. Also I love them.
have you already tried the latest alpha versions? It is working for me fine again with these.
If not I might need to increase the delay a bit more (it is very strange that this got so much slower on Tahoe, but I guess that is a system bug)
I just tested the latest alpha version and can confirm the issue is completely fixed!
The mouse gesture now works perfectly:
⢠âActivate/Bring to Front Window Under Cursorâ followed by âW
⢠Works flawlessly on background windows across all apps tested
⢠Even without any delay (I assume thereâs some built-in timing as you mentioned)
⢠The gesture drawing no longer interferes with cursor detection
I honestly didnât expect such a quick response, let alone a same-day fix suggestion. Your dedication to BetterTouchTool and the community is genuinely impressive. This kind of responsive support and development is rare, and itâs exactly why BTT is such an essential tool.
Thank you for taking the time to address this so quickly and for continuously improving an already amazing app. The gesture-based workflow is now exactly what I envisioned, and it works beautifully.
Much appreciated!
With Mouse Gesture trigger:
With Middle Mouse Button trigger:
