On macOS 26.5.2 (25F84), the built-in "Select the previous input source" shortcut (Control+Space) switches the input source and then reverts it roughly 100-500 ms later. The net effect is that the shortcut appears to do nothing.
The trigger is the timing of the two key-up events, not their order.
I reproduced this with synthetic events (CGEvent posted to .cghidEventTap), varying how long Space is held and the delay between the two key-up events. 15 trials per condition. "reverted" means the input source changed and then changed back, leaving the original source selected.
Space hold Key release persisted reverted no response
30 ms simultaneous 14 1 0
60 ms simultaneous 7 8 0
100 ms simultaneous 3 11 1
150 ms simultaneous 1 14 0
200 ms simultaneous 0 15 0
250 ms simultaneous 0 15 0
300 ms simultaneous 2 12 1
600 ms simultaneous 1 13 1
60 ms 20 ms apart, Space first 15 0 0
60 ms 20 ms apart, Control first 15 0 0
300 ms 20 ms apart, Space first 15 0 0
300 ms 20 ms apart, Control first 15 0 0
"simultaneous" means the two key-up events are posted back to back with no delay between them, so they land in the same event batch.
A 20 ms gap between the two key-up events makes it completely reliable: 60/60 trials across four conditions. Which key is released first makes no difference.
A separate monitor process polling TISCopyCurrentKeyboardInputSource recorded two input source changes per failing trial - the switch, then a revert 104-588 ms later - and exactly one change per trial in the four 20 ms-gap conditions.
Other things I checked:
- Not the input source machinery. Selecting the same two sources 25 times via TISSelectInputSource, with no keyboard involved, never reverted (0/25). The fault is in the hotkey path.
- Not key auto-repeat. Holding Control+Space does not cycle through input sources.
- No duplicate binding. AppleSymbolicHotKeys ID 60 is the only enabled system hotkey bound to keycode 49 with Control alone.
- Not specific to one IME. I see it with ABC and a third-party Japanese input method; Apple Community thread 256254361 reports the same behaviour with English and Russian, 16 "Me too", across multiple keyboards and applications. That reporter also confirms the Globe/Fn key is unaffected.
In a week of normal use a background monitor recorded 733 input source changes, of which 6.5-13.4% were a switch immediately followed by a revert (the range depends on the reversal threshold used: 250 ms to 1000 ms). Real-world reversal intervals were 135-433 ms, median 247 ms - inside the range seen in the synthetic reproduction.
One caveat on reproducibility: the 600 ms simultaneous-release condition varies between runs. An earlier run of the same matrix had it persisting 14/15 while the run above had it reverting 13/15. The 150-300 ms band failed in both runs.
Filed as FBxxxxxxxxx with a self-contained reproducer (single Swift file, ~170 lines, needs Accessibility permission and two or more enabled keyboard input sources).
Questions:
- Is the simultaneous-release behaviour intentional in any way, or is this simply a race in the hotkey handler?
- Is there a supported way for a user to make Control+Space reliable, short of moving to the Globe/Fn key or a third-party remapper?
- For anyone hitting this: does the 20 ms release gap also fix it on your machine? I would like to know whether the threshold is machine-dependent.