Issue with shortcut using character-above-tab-key on Monterey

[lwouis]

Hi!

Lots of AltTab users with non-English keyboards are reporting that shortcuts using the key above tab are not working since they upgraded to Monterey.

You can see the in-depth conversations on the ticket here: lwouis/alt-tab-macos#1190

Here are some examples:

I'm on a nordic layout and trying to use ⌘+§. It becomes ⌘+¥ after restarting AltTab.

I use option + and I've noticed that every-time I close and re-open AltTab the has changed to a strange long underscore character.

When I press the Command+º not having any associate program to it, it beeps (like "you are pressing a key combo that I cannot recognise") , when I assign it to Alt-tab, it keeps beeping...

Etc, it goes on, many cases with various behaviors. It seems something changed with Monterey that broke ShortcutRecorder.

Someone claimed to have found a patch to SR which fixes the issue:

I found a workaround for <:

+++ Pods/ShortcutRecorder/Library/SRKeyCodeTransformer.m
@@ -317,6 +317,10 @@
                                      implicitModifierFlags:0
                                      explicitModifierFlags:0
                                                 usingCache:YES];
+            
+            // Workaround
+            if (newTranslationToKeyCode[translation])
+                continue;
 
             if (translation.length)
                 newTranslationToKeyCode[translation] = keyCode;

I advised them to show you this, and ask for your expert opinion. I think they never did it. Here's their explanation of the fix:

If @Kentzo is willing to take a look, here is what happens: with an AZERTY layout, in keyCodeForTranslation of _SRKeyCodeASCIITranslator, translateKeyCode returns < for both SRKeyCodeGrave and SRKeyCodeJISUnderscore. Since keyCodeForTranslation keeps only the last value, it returns SRKeyCodeJISUnderscore.

Could you please tell me if this fix seems to make sense? I would like to use that in AltTab if it fixes the issue for people, but since I don't have non-English keyboards around, I won't be able to QA myself and confirms it works. That's why I would like to get your opinion before doing anything.

Thank you!

[Kentzo]

That's a tricky one. I'll see if I can reproduce it.

[lwouis]

@Kentzo any update? 🙇‍♂️

[frypf]

I'm one of the international layout users @lwouis mentions above - anything we can do to help with testing this solution?

[decodism]

Alternative workaround (not sure of code quality):

+++ Pods/ShortcutRecorder/Library/SRKeyCodeTransformer.m
@@ -165,5 +165,16 @@
     if (aKeyCode == SRKeyCodeNone)
         return @"";
+    
+    NSDictionary<NSNumber *, NSArray<NSNumber *> *> *layoutExclusiveKeyCodes = @{
+        @(kKeyboardISO): @[@(SRKeyCodeISOSection)],
+        @(kKeyboardJIS): @[@(SRKeyCodeJISYen), @(SRKeyCodeJISUnderscore), @(SRKeyCodeJISKeypadComma), @(SRKeyCodeJISEisu), @(SRKeyCodeJISKana)],
+    };
+    PhysicalKeyboardLayoutType currentLayoutType = KBGetLayoutType(LMGetKbdType());
+    
+    for (NSNumber *layoutType in layoutExclusiveKeyCodes) {
+        if ([layoutType intValue] != currentLayoutType && [layoutExclusiveKeyCodes[layoutType] containsObject:@(aKeyCode)])
+            return @"";
+    }
 
     anImplicitModifierFlags &= SRCocoaModifierFlagsMask;
     anExplicitModifierFlags &= SRCocoaModifierFlagsMask;

[Kentzo]

I'll look into this next week.

[lwouis]

I tried both fixes above (both are from @decodism) and it seems to fix the issue. My test use-case was to switch my Input Source to Spanish, and set a shortcut with the key-above-tab, which is < on the Spanish Input Source.

The shortcut then worked in AltTab. Without the diff above, it didn't trigger at all, and after restarting AltTab, the shortcut UI would show the weird long underscore (see screenshot in the OP).

So, I'm interested in integrating this fix, but I'm not sure which of the 2 approaches is better, and if they don't introduce regressions elsewhere. I'm not able to understand the inner workings of SRKeyCodeTransformer.m like @decodism seems to be able to, unfortunately. So I need to rely on @Kentzo for an review of the diff 🙇

[lwouis]

The root cause of the bug seems to lie in how: newTranslationToKeyCode (which is copied into _translationToKeyCode) is initiated.

Here is the diff (left is with the fix in the OP; right is current state):

Looking at the affected keys, I tried to use , and indeed it wasn't working without the fix. With the fix, it works fine.

[Kentzo]

What is the "nordic" layout you speak of, is it "Norweigian"?

[Kentzo]

I do not know whether it's possible to untangle issue. Your experience shows that the literal -> code mapping is not one-to-one, i.e. the same literal may be entered using different key codes depending on the current input source, physical keyboard and possibly other locale-specific settings. Furthermore this behavior may change between macOS releases.

That beings said, I think the API can be improved to gracefully handle all scenarios.