Safari Autofill Password Bug: False trigger on shift key

Bugs or Unexpected Behavior
1

Describe the bug
This is a weird one:
I have a key sequence triggered by a tap of the right shift key. It works great, triggering a keyboard shortcut almost everywhere.

I've found, though, that when typing a password into the Safari autofill dialog box (like the screenshot below), any shifted character will trigger a tap on the shift key, even though the keys are hit in the order: shift down-other key-shift release. It feels like Safari is consuming the key events and so BTT doesn't see them, but BTT is seeing the shift key anyways.

This means that when typing my password in that dialog box with the shifted character the BTT trigger gets hit and the password fails. I can type the same password in another app or text field without triggering BTT.

I hope this is clear. Let me know if there's any other information I can make available!

Thanks!

Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):
Any keyboard

Device information:

  • Type of Mac: MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports)
  • macOS version: Catalina 10.15.6 (19G2021)
  • BetterTouchTool version: 3.402

Additional information (e.g. StackTraces, related issues, screenshots, workarounds, etc.):
Screen Shot 2020-09-10 at 10.47.06 AM

2

Update: This also happens when typing into a password field to unlock System Preferences panels and App Store. Does not happen in Keychain Access or in regular Safari password fields on a web page.

3

Ah the problem is that these password fields activate a system-wide "secure input" mode. This mode prevents any other app from reading the current keyboard input. I think there is no way around that anymore (would be a security issue - I reported a few ways that still allowed this to Apple and they have since fixed them)

Maybe I can add a way to disable specific shortcuts when secure input mode is active.

4

Ah, that makes sense. I would expect that no shortcut that's triggered by keyboard input would be active during secure input mode. Thanks!

5

BTT can workaround the secure input restrictions for most shortcuts, but key sequences should be disabled

Unfortunately I haven't found a reliable way to immediately tell whether secure input is active... (BTT needs to poll the system state, doing it too often would cost too much performance)