fix(windows): resync caps lock state when Keyman keyboard is activated - #16423
fix(windows): resync caps lock state when Keyman keyboard is activated#16423MattGyverLee wants to merge 6 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
User Test ResultsTest specification and instructions
⬜ SUITE_CAPSLOCK:
Results Template |
|
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
left a comment
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.
|
@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>
User TestingTEST_RESYNC_CAPS_TEST
Regresion TestsTaken from #15771 Non-compliant On Windows 10 Test Test in Word, Firefox for compliant applications Non-compliant SUITE_CAPSLOCK:
Caps LockThe test keyboard layouts are found in the keyman repo at The test cases below expect the usage of the Prerequisites before each test
Test casesclick to expand
CapsAlwaysOffFor these tests, use a keyboard with the Any keyboard with that store set will work; if you don't have one at hand you can use the Note: When testing in a virtual machine, use an on-screen keyboard (in VirtualBox: Input/Keyboard/Soft Keyboard) and observe the caps lock indicator of the on-screen keyboard. Using the hardware keyboard might show side effects with caps lock. Prerequisites before each test
Test casesclick to expand
SHIFT: CapsOnOnly/ShiftFreesCapsFor these tests, use a keyboard with the Any keyboard with these stores set will work; if you don't have one at hand you can use the The shift_frees_caps.kmp keyboard will enable caps lock by pressing the Note: When testing in a virtual machine, use an on-screen keyboard (in VirtualBox: Input/Keyboard/Soft Keyboard) and observe the caps lock indicator of the on-screen keyboard. Using the hardware keyboard might show side effects with caps lock. Except for TEST_CAPSONLY-5 which can only be reliably tested on a hardware keyboard on host OS (not a VM). For windows 10 and windows 11 with a virtual box vm-onscreen keyboard, the following happens. The VM soft keyboard does NOT actually send the Shift Shift Key Stroke through but rather will change the keys pressed for example if an Prerequisites before each test
Test casesclick to expand
|
rc-swag
left a comment
There was a problem hiding this comment.
Just a suggestion for the comment.
LGTM
Co-authored-by: rc-swag <58423624+rc-swag@users.noreply.github.com>
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:
Fixes: #16422
Build-bot: release:windows