fix(windows): resync caps lock state when Keyman keyboard is activated - #16423
Open
MattGyverLee wants to merge 5 commits into
Open
fix(windows): resync caps lock state when Keyman keyboard is activated#16423MattGyverLee wants to merge 5 commits into
MattGyverLee wants to merge 5 commits into
Conversation
The Caps Lock and Num Lock flags in Globals::ShiftState() are updated only as key events pass through the engine, so they go stale when the toggle is changed while a non-Keyman layout is active. The existing resync in GetCapsAndNumlockState() runs on window focus change, which a keyboard switch does not trigger, so the core processor was told Caps Lock was off until the user toggled it twice. Extract the toggle resync as RefreshToggleState() and call it from TIPActivateKeyboard(), which is the profile activation path for both Win+Space and the Windows language selector. Fixes keymanapp#16422 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011GdFpFi5eqJP6C1YjuQytY
keymanapp-test-bot
Bot
added
the
user-test-missing
User Test ResultsTest specification and instructions ERROR: user tests have not yet been defined |
Collaborator
|
This pull request is from an external repo and will not automatically be built. The build must still be passed before it can be merged. Ask one of the team members to make a manual build of this PR. |
mcdurdin
self-requested a review
August 22, 2026 06:31
mcdurdin
reviewed
Aug 22, 2026
mcdurdin
left a comment
mcdurdin
left a comment
Member
There was a problem hiding this comment.
Thank you for your contribution. This looks pretty straightforward and clean. We will need to test this in conjunction with the caps lock stores, in particular &CapsAlwaysOff, to ensure that we get a consistent result, and I would like @rc-swag to sign off on the change.
Member
|
@rc-swag can you write up some user tests for this also? |
Co-authored-by: Marc Durdin <marc@durdin.net>
Co-authored-by: Marc Durdin <marc@durdin.net>
Co-authored-by: Marc Durdin <marc@durdin.net>
Co-authored-by: Marc Durdin <marc@durdin.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Here's a proposed fix for #16422 .
Full disclosure, Claude built this minimal fix. I have reviewed the result and tested it by inserting a rebuilt keyman32 and keyman64 DLLs in place. It's just displacing code, nothing new. Rereading the state of the system's locks on keyboard load makes sense to me.
I tested moving with Win+Space and via mouse between the Windows US English and Keyman Cameroon Keyboard. CAPS was detected when the Cameroon Keyboard activated and the first output letter was a capital. It worked well. I noted that switching to yoruba8 ignored the existing CAPS state without disabling it on the system, but this is expected since that keyboard doesn't have CAPS rules.
From Claude: