With the “Include currently pressed modifier keys” option enabled, continuing to hold down a modifier when triggering a shortcut no longer seems to prevent a keyup event being emitted for the modifier.
The issue appeared after upgrading from 5.800 to 6.194 and persists with 6.202 alpha. Reverting to 5.800 makes the problem go away, suggesting a BTT regression. I’m using macOS Sequoia 15.7.3.
The strange thing is that I’m only experiencing the issue with Firefox, but nothing has changed in the app itself.
FF has a nice feature where you can set the tab switcher (Ctrl+Tab) to function similarly to the Cmd+Tab app switcher. By keeping Ctrl pressed, you can use Tab / Shift+Tab to navigate a tab picker displaying thumbnails of the most recently used tabs.
In BTT, I have mapped Ctrl+. and Ctrl+, to Tab and Shift+Tab, respectively. With the option “Include currently pressed modifier keys” set, this has worked perfectly to operate the tab switcher. The highlighted tab would get activated once I release Ctrl.
With BTT 6.194 and 6.202, triggering the shortcut (while continuing to hold Ctrl) causes an instant jump to the most recent tab. This behaviour is as if the Ctrl key were released immediately.
However, when I implement the same action for VS Code (which also has the same kind of MRU editor switcher bound to Ctrl+Tab), it works just fine. The quick open menu stays open until I release Ctrl.
Could the two apps have different methods of listening to keyboard events, only one of which is affected?
Attached are two keyboard event logs from Firefox. Both are recordings of two consecutive presses of Ctrl+Tab without releasing Ctrl in between. One reflects native behavior, while the other is the result of BTT-generated events. The latter shows an unwanted keyup event at line 54 and another superfluous (but harmless) keyup at the end.
Native:
Ctrl down
Tab down
Tab up
Tab down
Tab up
Ctrl up
BTT:
Ctrl down
Tab down
Tab up
Ctrl up
Tab down
Tab up
Ctrl up
Ctrl up