[KeyboardManager] Fix sticky Ctrl caused by stale AltGr flag#46672
[KeyboardManager] Fix sticky Ctrl caused by stale AltGr flag#46672fluffyspace wants to merge 3 commits intomicrosoft:mainfrom
Conversation
…d flag The static isAltRightKeyInvoked flag was set to true when AltGr (RAlt+LCtrl) was pressed, but only reset inside Case 1's else branch which requires an active shortcut invocation. If AltGr was pressed when no shortcut was active, the flag stayed true permanently, blocking modifier restoration and state resets throughout HandleShortcutRemapEvent, causing LCtrl to become stuck. Reset the flag when VK_RMENU is released regardless of shortcut state. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Fixes a KeyboardManager shortcut-remap edge case where a stale isAltRightKeyInvoked (AltGr) flag can prevent proper modifier restoration, leading to “stuck Ctrl” behavior.
Changes:
- Adds logic to clear
isAltRightKeyInvokedonVK_RMENU(Right Alt) key-up events insideHandleShortcutRemapEvent.
| @@ -307,6 +307,10 @@ namespace KeyboardEventHandlers | |||
| { | |||
| isAltRightKeyInvoked = true; | |||
| } | |||
| else if (data->lParam->vkCode == VK_RMENU && (data->wParam == WM_KEYUP || data->wParam == WM_SYSKEYUP)) | |||
There was a problem hiding this comment.
The new reset branch for isAltRightKeyInvoked can be skipped on VK_RMENU key-up events: the preceding if (vkCode == VK_RMENU && ii.GetVirtualKeyState(VK_LCONTROL)) also runs on key-up, and if VK_LCONTROL is still reported as down at that moment (common with AltGr), it will set the flag back to true and prevent the reset. To ensure the flag is reliably cleared on release, handle the key-up case first (or gate the "set" branch to key-down only).
|
@fluffyspace What issue is this PR closing? |
Three test cases covering the bug where isAltRightKeyInvoked stays true after AltGr is pressed without an active shortcut: 1. Basic: AltGr press-release followed by shortcut invoke and full key release — verifies state resets properly 2. Revert: AltGr press-release followed by shortcut with extra key pressed — verifies Case 3 else path restores modifiers 3. Repeated: Multiple AltGr press-release cycles followed by shortcut — verifies no accumulated corruption Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@niels9001 Apologies for the missing link — the issue was filed after the PR was initially created. It's now linked in the description: The PR description has been updated with the full root cause analysis and test plan. |
|
@microsoft-github-policy-service agree |
The set branch for isAltRightKeyInvoked did not check for key-down, so on VK_RMENU key-up with LCtrl still held (normal AltGr release order) it would re-set the flag to true before the reset branch could execute. Add WM_KEYDOWN/WM_SYSKEYDOWN check to the set condition so the else-if reset on key-up is reached reliably. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
niels9001
added
the
Product-Keyboard Shortcut Manager
Summary
Fixes #46693
static bool isAltRightKeyInvokedflag inHandleShortcutRemapEventis set when AltGr (RAlt+LCtrl) is pressed, but only reset inside Case 1's else branch — which requires a shortcut to be actively invoked (isShortcutInvoked == true)truepermanently across all future callsbreakout of the handler loop (line 620-622) instead of being properly processedFix
Reset
isAltRightKeyInvokedwhenVK_RMENU(Right Alt) is released, regardless of whether a shortcut is currently invoked. This is added as anelse ifright after the existing flag-set condition.Test plan