Bug that needs constant disable/enable of BTT to work

Describe the bug
Few months ago I noticed that some keys occasionally stop working. I figured out that these keys are used in my BTT settings for specific apps. E.g. I use \ slash in Mail app for zoom, and I can’t write this \ slash in Safari or Finder. Same with other keys and combinations.

BTT disable/enable returns everything back to normal. But after last update I need to disable/enable literally every time I switch apps.

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):
Keyboard (I’m not sure but maybe mouse commands too).

Device information:

  • Type of Mac: Late 2012 iMac
  • macOS version: El Capitan
  • BetterTouchTool version: 2.606

Yes! This bug has been affecting me as well, and it started with 2.6. I have been upgrading to each Alpha release in the hopes that the bug doesn't resurface and while I haven't yet experienced it on 2.610 I had experienced it on 2.608.

I notice it most with cmd+W in Safari, but it affects other keypresses in other apps. I will switch into Safari from some app and press cmd+W to start closing tabs and nothing will happen. I do not have cmd+W bound to anything in Safari. It's like BTT holds onto the keypress doesn't deliver it properly (perhaps it delivers it to another process?). Restarting BTT will fix things again for a while, and I haven't yet been able to pin down the exact steps to reproduce the issue (it isn't simply switching from a certain app, so far as I can tell).

For the record, I have cmd+W bound to one of two things for a few apps in BTT, mostly to force apps to quit when they have no more active windows so they don't stick around on the Dock.

BTT Activity Monitor -> cmd+W simulates cmd+Q
BTT TextEdit -> cmd+W runs an AppleScript (async) that counts the number of TextEdit windows & issues a close or quit command depending. I have this same script bound to cmd+W in Preview. (I hate having TextEdit and Preview stick around on my Dock after I've closed all their open windows.) The script is below, if it helps.

tell application "TextEdit"
if (count of windows) is 1 or (count of windows) is 0 then
close window 1
end if
end tell

I would love to help squash this bug as since 2.6 has been out I've been going crazy with having to restart BTT. I have an AppleScript I wrote forever ago (not due to this bug, but for something else) that automates the process (I invoke it using Alfred):

tell application "BetterTouchTool" to quit
delay 2
tell application "BetterTouchTool" to launch

My BTT -> Advanced Settings -> Keyboard option before 2.6 was set to "Always use old keyboard shortcut implementation" and after 2.6 I have tried every combination of those two settings and the bug still happens pretty regularly.

I would estimate I have had to restart BTT about 7-10 times today. Pre 2.6 I did not have to ever restart BTT, maybe once a week when snap areas would bug out.

If there's any more info I can provide to the dev to assist with this please let me know :slight_smile:

Unfortunately I haven't experienced something like this yet.
@lucastatic, on which version of macOS are you?

Could you both go to the About tab in BetterTouchTool and click the "Export Debug Information" button? This will create a folder called "BetterTouchToolDebug" on your desktop - sending that to andreas@folivora.ai could maybe help me see what's wrong.

This is happening to me for a couple weeks now, it seems to be getting worse. Even earlier I believe it was happening, but I was able to stop it from being an issue by using the "old" keyboard setting which avoids secure touch. Now, it is always happening and I cannot use BTT anymore. I hope you can fix it.

I think I may have found a little issue. Would be great if you could test v 2.617 alpha

@Andreas_Hegenberg, I'm on macOS 10.13.6. I've sent you the debug information. The issue persists on 2.618.

Here are my guaranteed steps to reproduce the problem. It appears to be related to the old keyboard shortcut implementation in relation to secure input.

Old keyboard shortcut implementation must be enabled (either by the "Always use" or the "Switch to when secure input enabled" options)

Open BTT
Open Safari, cmd+W works
Open TextEdit (where I have a cmd+W bound, if that matters), cmd+W works
Open Safari, cmd+W will not work
Restart BTT, Safari is still in foreground, cmd+W works again
Open TextEdit, cmd+W works
Open Safari, cmd+W will not work, etc


This bug appears to only occur in the above situation if Secure Input is currently enabled by Safari. I noticed in the BTT menu that it said Secure Input had been enabled by Safari. If the old keyboard implementation is active in any way when Secure Input is also active, then cmd+W doesn't work in Safari.

Interestingly, there were no tabs or anything requiring Secure Input open in Safari anymore (there had been earlier in the day). I quit Safari to clear the Secure Input flag, which caused it to vanish from BTT's menu, and then reopened Safari and things are working fine. Going to a page that has a password box doesn't appear to invoke Secure Input so I'm not sure what does. ...Hmm, looks like it's when I opened the Safari Preferences and went to the Passwords tab where it asks for your password.

Thank you! I think that helped me find the issue.
Would be great if you could test v2.619

Thanks for the quick update :slight_smile:

I've just upgraded to 6.220. I have the "use old shortcut implementation when Secure Input enabled" setting checked. I just tested enabling Secure Input by having Safari show its Preferences > Passwords login prompt. Then I switched to TextEdit, where my cmd+W shortcuts worked and then switched back to Safari where they continue to work! It seems things are working correctly now with shortcuts being delivered. Thanks @Andreas_Hegenberg ! I'll post back here if I see the issue resurface.

Hi again, @Andreas_Hegenberg. I just updated to Alpha v2.648 (958) and am experiencing the issue where keyboard shortcuts (specifically my cmd+W as referenced earlier in this thread) aren't being sent to the applications in the foreground again. I am however not noticing BTT citing anything has enabled Secure Input Mode so I don't know if it's related to that.

Mh, it seems to work fine here, but there have been some changes in the alpha that could relate to keyboard shortcuts.

Have you already tried to restart BTT? Does it recognize other shortcuts?

I've reset BTT a number of times and the issue usually comes when I switch apps, in this case from TextEdit to Safari. Some keyboard shortcuts stop working when this happens, like cmd+T etc don't create new tabs in Safari, cmd+W doesn't close tabs, but cmd+O brings up the Open dialog. I only have cmd+N and cmd+shift+N bound in BTT Safari.


I've isolated the bug.

If a key combo is BTT bound in one app (AppA) and I switch to another (AppB), the key combo bound in AppA will not work in AppB.

For example, I have cmd+T and cmd+W BTT bound in TextEdit. If I switch to Safari, cmd+T and cmd+W will stop working in Safari until I restart BTT. (Similarly, if I were to switch to Xcode after that, cmd+T and cmd+W will also not work there. Quitting TextEdit doesn't fix the issue either.)

Similarly, I have cmd+shift+B bound in another app and when I switch to Xcode I cannot use cmd+shift+B anymore.

Thanks a lot for figuring that out! Should be fixed in v2.650 alpha now

Awesome, thanks again!