You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
delegate active-IME Process/keyCode 229 events to xterm's native CompositionHelper
remove the redundant Android orphan-input fallback so xterm remains the single input owner
send the browser's committed input text from the explicit CJK field instead of guessing from KeyboardEvent.key
cover the complete full-width punctuation sequence on desktop and touch-capable Chromium
Root cause
Codeman's custom xterm key handler returned false for keyCode 229 before xterm could run its CompositionHelper. Active Chinese IMEs use a non-composing 229 event when committing numbers and punctuation, so the subsequent textarea change never reached terminal onData. The separate CJK input field also prevented the printable keydown and sent its physical ASCII key before the IME could transform it.
The fix delegates these events to xterm and treats the final InputEvent/textarea value as the canonical Unicode text. There is no punctuation-specific mapping.
Test plan
npm test — 5368 passed, 12 skipped
npm run test:browser -- test/terminal-copy-shortcut.test.ts — 8 passed
npm run typecheck
npm run lint
npm run format:check
npm run check:frontend-syntax
npm run check:public-assets
npm run build
The browser regression commits Chinese text first, then verifies each character in ,。!?;:“”、《》、() reaches terminal onData exactly once in both desktop and touch-capable contexts.
Thank you! This is the right root-cause fix. Returning false for keyCode 229 was stopping xterm before its CompositionHelper could diff the helper textarea, so the committed text never reached onData, and sending KeyboardEvent.key from the CJK field could never preserve what the IME actually committed. Delegating to xterm and treating the final input text as canonical also makes the old Android orphan-input fallback redundant, so removing it leaves exactly one input owner instead of a stack of double-send heuristics.
Verified locally on top of #331: full test gate green, and npm run test:browser -- test/terminal-copy-shortcut.test.ts passes (8 tests, including your new full-width punctuation regression on both desktop and touch-capable Chromium).
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
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.
Summary
Root cause
Codeman's custom xterm key handler returned false for keyCode 229 before xterm could run its CompositionHelper. Active Chinese IMEs use a non-composing 229 event when committing numbers and punctuation, so the subsequent textarea change never reached terminal onData. The separate CJK input field also prevented the printable keydown and sent its physical ASCII key before the IME could transform it.
The fix delegates these events to xterm and treats the final InputEvent/textarea value as the canonical Unicode text. There is no punctuation-specific mapping.
Test plan
The browser regression commits Chinese text first, then verifies each character in ,。!?;:“”、《》、() reaches terminal onData exactly once in both desktop and touch-capable contexts.