Trackpad becomes unresponsive after revoking Accessibility permission

[Ilya Rodionov]

Steps to reproduce:

• Run MiddleClick.
• Grant MiddleClick access to Accessibility in System Settings > Privacy & Security.
• Revoke Accessibility permission. Or run tccutil reset Accessibility in terminal to reset Accessibility settings.

Expected result:
MiddleClick stops working, other things work.

Actual result:
Trackpad becomes unresponsive and it's not possible to click with it (some gestures work though).

MiddleClick 2.6.1
macOS 13.2.1

P.S.: killing MiddleClick or just logout(Cmd-Shift-Q) helps.

[Arthur Ginzburg]

Yep, that’s been a long-standing issue. There is a simple way to prevent that — checking Accessibility permissions every second or so and stopping the listeners if the accessibility permission gets lost (the same way the app works after launch, just boolean-inverted). I’m not sure if this is the best solution.

Obviously, for maintainability of this app it would be better to use an already existing library implementing Multitouch. I majorly dislike the fact that the multitouch logic and the middle click logic is in the same file.

[Ilya Rodionov]

In Touch-Tab I've switched from Multitouch to CGEventTap. I use .listenOnly option and it doesn't make trackpad unresponsive on revoking Accessibility permission, using .defaultTap does though.

[Arthur Ginzburg]

This .listenOnly option (kCGEventTapOptionListenOnly in Obj-C) is magic! Indeed, it leaves the trackpad responsive on revoking Accessibility permission.

The only thing I noticed is that with that option, on Ventura, MiddleClick starts asking for Input Monitoring instead of Accessibility, even though it works fine with just the Accessibility.

Another strange thing is that sometimes when I granted the Input Monitoring just for a test, the Accessibility permission became granted automatically, but sometimes it did not. Couldn't catch any pattern here.

[Ilya Rodionov]

Have you tried using AXIsProcessTrustedWithOptions? It allows to prompt a user to grant Accessibility permission.

[Arthur Ginzburg]

Just tried that — MiddleClick now asks for Accessibility permission, as intended. Good. Thanks!

I also like that running AXIsProcessTrustedWithOptions on an interval makes it essentially a persistent prompt that cannot be closed until the app is closed. Might seem unintended for someone, but actually it's useful because unlikely the user will be willing to keep the app open without giving it the permission.

[Arthur Ginzburg]

There is a problem with this .listenOnly approach: if "Tap to click" is disabled — the app stops doing anything. mouseCallback() doesn't get called. The fun thing though is that the app seems to read clicks when the pointer is right above the app's menu bar icon.

In the end, I got it working by granting the "Input Monitoring" permission additional to the "Accessibility" permission. I guess that's why the app was initially asking for it until we suppressed it with AXIsProcessTrustedWithOptions.

[Ilya Rodionov]

I believe (may be I'm wrong about that) that if an app has Accessibility permission it doesn't need to haveInput Monitoring permission granted. In other words Accessibility permission contains Input Monitoring permission.

Could you try not to start any input monitoring until Accessibility permission is granted? It works for me in Touch-Tab.