Delayed clicks and beach balling

Describe the bug
I've had a performance issue on my computer for months where clicking windows, or clicking anything (channels in Slack or something) sometimes takes a second or two to take effect, and sometimes the beach ball shows up. I actually got a new computer because I thought it was a hardware issue, but it kept happening on the new computer. Finally tracked it down to BTT - it doesn't happen when BTT isn't running. This is very annoying.

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):
I use a Magic Mouse and the only rule I have defined is Three Finger Click -> Middle Click.

Device information:

  • Type of Mac: MacBook Pro 2017 13"
  • macOS version: 10.14.4
  • BetterTouchTool version: 2.800

I haven't seen any weird activity in Activity Monitor in terms of rogue CPU usage or anything. I do not have Dropbox syncing on (don't even have Dropbox installed)

stuff like this is pretty much always caused by two apps using the same technique to capture events on macOS (CGEventTaps).

Can you think of any other app you have installed that might need to work with global mouse or keyboard events?

I'll add a way to identify possible conflicts with one of the next BTT versions.

I'm not running any apps that I'm using specifically for mouse / keyboard control, but maybe one is unknowingly conflicting? The other apps in my Privacy > Accessibility whitelist are Alfred 3, Dash, and iTerm. Could any of those pose an issue?

Mhh I'm also using Alfred and iTerm, so those two shouldn't be it. The creator of Dash is also using BTT as far as I know, so I would also rule that out, but I'll check it!

I think I might be able to add a way to log possible conflicts tomorrow, wanted to do this for quite a while anyways.

Ok, let me know when that becomes available

Actually @Andreas_Hegenberg I think I've narrowed it down to BTT and Slack. When both are running, and I click on Slack and then click either in the app or outside the app, there's a delay which doesn't happen when BTT is not running. I'm not sure why Slack would be conflicting with the APIs you're using, but maybe it is?

Interesting! Could this be related to window snapping? (apps need to support a macOS API for this to work correctly - as Slack is using Electron, maybe they didn't implement it correctly).

Could you try to disable window snapping for slack?

I'm experiencing the same slowdowns as @galonsky with Slack and BTT. Disabling window snapping for Slack (or, for that matter, disabling BTT completely for Slack) definitely has a positive impact, although it still feels a bit more responsive when I quit out of BTT entirely.

1 Like

Yeah, disabling window snapping for Slack is definitely helping for me. It's probably too early to tell - not sure if that completely fixes the issue or just makes it better like @jkantzer

1 Like

Sounds good! Maybe I need to download Slack and do some tests :slight_smile:

However if BTT is completely disabled for Slack it may be a "nocebo" effect :slight_smile: - when disabled BTT shouldn't interact with any events anymore while Slack is the active app @jkantzer .

Makes sense! Marginal differences are somewhat hard to notice since Slack is far from the most performant application even at its best.

I have the same issue, I'll disable snapping for Slack :frowning: And see if that helps, does it look like there will be any way to fix this?

I'll report the issue to slack, they will need to fix it unfortunately (not sure what they are doing because in general electron apps support the necessary API just fine).

I experienced the same issue and was able to isolate it issue down to BTT and Slack, quitting BTT eliminates the problem.

I tried turning off the windows snap, but it doesn't 100% get rid of the issue.

The only way to get rid of the delay is to turn off BTT entirely.

I did the test and recorded it so you can have a look here :

If possible please also report the issue to Slack, this is not really a BTT bug, but a Slack bug where it doesn't seem to be able to react to Accessibility API requests fast enough. (It should either respond fast or not at all and definitely not beachball)