fix(term): correctly map Ctrl+[ to ESC on non-US keyboard layouts#3406
fix(term): correctly map Ctrl+[ to ESC on non-US keyboard layouts#3406Jason-Shen2 wants to merge 2 commits into
Conversation
On some Linux keyboard layouts, xterm.js may misidentify Ctrl+symbol key combinations (e.g. reporting Ctrl+] when Ctrl+[ is pressed), because event.key reports the wrong character when Ctrl is held. - Extend keyboardEventToASCII to handle all single-char Ctrl combos using the standard charCode & 0x1F formula (not just A-Z) - Add event.code-based fallback for bracket/backslash keys to correctly identify physical keys regardless of keyboard layout - Add fallback handler in handleTerminalKeydown to send correct ASCII control codes for Ctrl combos not already handled by app keybindings Fixes wavetermdev#3334
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Walkthrough
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/util/keyutil.ts`:
- Around line 292-297: The ctrlCodeMap fallback in keyutil.ts is still missing
the Slash physical key, so update the key-to-byte mapping used by the Ctrl key
handling to include Slash alongside BracketLeft, Backslash, BracketRight, and
Space. Make the change in the ctrlCodeMap object so the code-based path in the
key processing logic recognizes Slash even when event.key is localized on non-US
layouts.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 0d01705b-384e-48cb-8d25-4e7118c07f2f
📒 Files selected for processing (2)
frontend/app/view/term/term-model.tsfrontend/util/keyutil.ts
CodeRabbit review identified that the ctrlCodeMap was missing the Slash physical key, which would cause non-US layouts that surface a localized event.key for the slash key to compute the wrong Ctrl byte.
|
Fixed in 8038d25: added |
1 participant
Summary
Fixes a bug where pressing Ctrl+[ was incorrectly sending Ctrl+] (GS, \x1d) instead of ESC (\x1b) on some Linux systems with non-US keyboard layouts.
Root Cause
The
keyboardEventToASCIIutility only handled Ctrl+A-Z letter keys, leaving other standard terminal control characters (Ctrl+[ → ESC, Ctrl+\ → FS, Ctrl+] → GS) to be processed by xterm.js. On non-US keyboard layouts, the browser may report an incorrectevent.keyvalue when Ctrl is held (e.g. reporting "]" when the physical "[" key is pressed), causing xterm.js to send the wrong control character.Changes
frontend/util/keyutil.ts:keyboardEventToASCIIto handle all single-character Ctrl combos using the standardcharCode & 0x1Fformula (not just A-Z)event.code-based fallback map for bracket/backslash/slash keys to reliably identify physical keys regardless of keyboard layoutevent.keywhen Ctrl is held for known physical keysfrontend/app/view/term/term-model.ts:handleTerminalKeydownthat uses the fixedkeyboardEventToASCIIto send correct ASCII control codes for Ctrl+key combos not already handled by app keybindings (paste, copy, tab switching, etc.)Fixes #3334