[bug][alpha] Which Key (`WhichKey`): `keydown` with `repeat === true` extends the pending chord and can cancel the sequence

[brianPho]

Project

ide

Description

WhichKeyProvider installs a capture-phase window keydown listener (WhichKeyContext.tsx). When a chord prefix is already pending, the next key appends to the sequence:

const newPrefix = [...currentSequence.keystrokes, keystroke];

There is no if (event.repeat) return (or equivalent). Holding a key so the OS/browser emits auto-repeat keydown events appends duplicate Keystroke entries to newPrefix. That usually fails findContinuations(newPrefix) and hits the branch that calls cancelSequence() — the user loses the in-progress chord even though they only held a modifier or key as part of a multi-step binding.

This is independent of IME (inputs are skipped) and independent of SELECT interception (already reported on bounty: WhichKey runs when focus is on <select> because only INPUT / TEXTAREA / contentEditable are excluded).

Error Message

Debug Logs

System Information

Cortex IDE alpha
Windows / macOS / Linux (any OS that emits key repeat)

Screenshots

Steps to Reproduce

1. Ensure Which Key is enabled (settings).
2. Start a key chord that the app treats as a prefix (so showForPrefix runs and a sequence is pending).
3. Hold the key that produced the first Keystroke so repeat events fire before completing the chord.
4. Observe that the sequence may cancel (cancelSequence) instead of staying open for the next deliberate key.

Expected Behavior

Auto-repeat keydowns should not advance or corrupt chord state (typically ignore event.repeat while a Which Key sequence is active, or treat repeat as a no-op for chord extension).

Actual Behavior

Repeat events append to newPrefix and can invalidate the sequence.

Additional Context

No response

[echobt]

✅ Validated

VALID: This is a legitimate bug in the WhichKey component. The code analysis confirms that WhichKeyContext.tsx (lines 303-384) has a handleKeyDown listener that processes key events without checking event.repeat. When a chord sequence is pending and a key is held down, auto-repeat keydown events append duplicate keystrokes to the sequence (e.g., ['Ctrl','K'] becomes ['Ctrl','K','K']), causing findContinuations() to fail and incorrectly calling cancelSequence(). The fix would be to add if (event.repeat) return; early in the handler. The WhichKey component is properly integrated into the app via WhichKeyProvider in OptimizedProviders.tsx and rendered in AppCore.tsx, making it accessible to users. Duplicate check confirmed this is NOT a duplicate of #36432 (SELECT focus) or #33869 (Component Preview) - the root cause is distinct (key repeat handling in chord sequences). Screenshot was inaccessible (404) but keyboard bugs are difficult to capture visually and the code evidence is conclusive.

[willkhinz]

I've got a surgical fix for this. Just running some quick local tests and will post the PR soon.

[willkhinz]

I have opened a Pull Request with the fix here: #37721

Thanks!