Global shortcut fails when focused field is a password field

[lwouis]

Pressing alt-tab here doesn't trigger the app. Somehow the tab event is not propagated to the app in that case, potentially for security purpose.

There may or may not be a way to work around this behaviour.

[lwouis]

The built-in command-tab shortcut works in that scenario. This either means there is a way to work around the tab key being absorbed by the password field, or that it has security privileges as an OS tool.

[lwouis]

I tested other apps and here are the results:

• AltTab: tab keypress is absorbed by AltTab
• HyperSwitch: tab keypress is sent to the password field
• WindowSwitcher: works fine!

WindowSwitcher shows that it's possible and not an OS limitation

[lwouis]

It seems the current CGEvent.tapCreate hides keypresses on password fields. However, the OS has other APIs to do it.

Solution would be to use a OSS library handling shortcuts correctly (even passwords):

• MASShortcut
• ShortcutRecorder
• CGSKeyboardShortcut

This would also help with the #49 story

[lwouis]

I can confirm that ShortcutRecorder is not affected by the limitation. Using GlobalShortcutMonitor which internally uses the Carbon API let's us intercept the event before it reaches the password field, somehow. This seems to me like a clear security breach on Apple's part that anyone can keylog password field using old-but-still-available APIs.

[lwouis]

More context from Apple on what's happening on a password field

[lwouis]

I'm closing this ticket as I'm actually happy that the current implementation is respecting the password field design to not let other apps read keys on a password field.

Even if I could do it, I wouldn't want to do it. It's a very rare and minor inconvenience to not be able to switch windows when focus is on a password field, but the reward is more security.