Skip to content

fix(opposite-shift): shift stuck when both shifts are held (@TharunBabu-05) - #8431

Open
TharunBabu-05 wants to merge 1 commit into
monkeytypegame:masterfrom
TharunBabu-05:fix/opposite-shift-stuck
Open

TharunBabu-05 wants to merge 1 commit into
monkeytypegame:masterfrom
TharunBabu-05:fix/opposite-shift-stuck

Conversation

@TharunBabu-05

@TharunBabu-05 TharunBabu-05 commented Sep 29, 2026 •

Copy link
Copy Markdown

Description

Fixes a problem with Opposite Shift Mode, where the Shift key state could get stuck when pressing both Shift keys one after another and then releasing them.## Repro Steps (Windows)

Steps to reproduce (Windows)

  1. Activate Opposite Shift Mode.
  2. Press and hold the Right Shift key.
  3. Hold down Right Shift and press and hold Left Shift.
  4. Right Shift – First release.
  5. Release Left Shift
  6. Type a lower-case o, p, or l.
  7. Character is rejected incorrectly because app still thinks a Shift key is held down.

Root cause

If you hold both shift keys down simultaneously in Windows, then release the first one, you may not get a key-release event for it while the other shift key is held down.

That is , the Shift key pressed earlier can still be marked as held in the internal state of the application .

This stale state can result in subsequent lowercase characters being treated as if the Shift key were still held down, even when both Shift keys have been released.

Fix

Updated the keyboard event handling to clear the internal Shift-key state when the browser reports that no Shift key is currently held (e.shiftKey === false).

The capture phase updates the Shift-key state through listeners. This makes sure that the Shift-key state is cleared before the Opposite Shift Mode check.

This ensures that:

  • When the browser reports that no Shift key is held, both internal Shift states are cleared.
  • Opposite Shift Mode uses the current Shift-key state when validating a keystroke.
  • A stale Shift state no longer causes subsequent lowercase characters to be incorrectly rejected.
  • Existing Shift-key behavior is preserved.

Known limitation

While one Shift key is still held, the other Shift key may remain marked as held internally because Windows does not provide a key-release event for the first Shift key in this specific sequence.

The internal state is corrected once the browser reports that no Shift key is held.

Testing

Tested on Windows with Opposite Shift Mode enabled.

Manual testing

Confirmed the following cases:

  • Pressing Right Shift normally.
  • Pressing Left Shift normally.
  • Pressing both Shift keys sequentially.
  • Releasing Right Shift first and then Left Shift.
  • Typing lowercase o, p, and l after both Shift keys are released.
  • Opposite Shift Mode correctly handles the Shift state after both keys are released.

Unit tests

Added:

Path: frontend/tests/states/modifiers.spec.ts
→ 4 of the 5 tests fail on master
"All tests pass with the fix" → "all 5 pass with the fix"

Checks

  • Related issues checked.
  • PR title follows Conventional Commits.
  • GitHub username included in title.

Closes #8386

…bu-05)

On Windows, holding both shift keys only fires keyup for the last one
released, so the other stays marked as held and opposite shift mode
rejects normal key presses until that shift is pressed again.

- resync left/right shift from event.shiftKey on every key event
- track modifiers in the capture phase so the state is updated before
  the input keydown handler reads it

Fixes monkeytypegame#8386

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Copilot AI balanced review requested due to automatic review settings September 29, 2026 15:09

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@monkeytypegeorge monkeytypegeorge added the frontend User interface or web stuff label Sep 29, 2026
@github-actions github-actions Bot added the waiting for review Pull requests that require a review before continuing label Sep 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

frontend User interface or web stuff waiting for review Pull requests that require a review before continuing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

normal key input is falsly rejected by opposite shift mode

3 participants