Uh oh!
There was an error while loading. Please reload this page.
Ctrl+C over a selection copies instead of interrupting - #76
Merged
Conversation
xterm encodes Ctrl+C as ETX with no notion of a selection, so copying output sent SIGINT to the program under it. The custom key handler now stands aside for Ctrl+C over a selection so the browser's own copy runs, then clears the selection so the next press still interrupts. Ctrl+Shift+C is claimed for copy (unclaimed it opens DevTools) and Ctrl+Shift+V for paste. Mac keyboards keep Ctrl+C as the interrupt: Cmd+C already copies there. Closes#62
Chromium and Firefox on Windows and Linux bind the chord to a plain-text paste that fires a trusted paste event xterm already consumes, bracketed paste included. Claiming it and reading the async clipboard cost a permission prompt on those platforms and went dead on insecure origins, where navigator.clipboard does not exist. Also guard a clipboard object without writeText, and restore the clipboard stubs after each test.
Uh oh!
There was an error while loading. Please reload this page.
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Closes#62.
What happens now
Select output with the mouse and press Ctrl+C: the selection is copied and the program keeps running. With nothing selected, Ctrl+C is still the interrupt it has always been. Ctrl+Shift+C is claimed for copy, so the chord no longer opens the DevTools inspector over the terminal. Ctrl+Shift+V is deliberately left to the browser, which already binds it to a plain-text paste on Windows and Linux.
How
All in the custom key event handler in
web/src/emulator/xterm.ts, the seam the issue pointed at.falsewithoutpreventDefault. xterm never encodes ETX, the browser's own copy runs, and xterm's copy listener fills the clipboard from the selection. The selection is then cleared on a deferred tick, so the next Ctrl+C interrupts: a held selection must not make SIGINT unreachable from the keyboard.preventDefault, write the selection throughnavigator.clipboard, clear it on success only. A failed write keeps the selection, so there is something to try again with. An empty selection is swallowed rather than passed on, which is what keeps DevTools shut.XtermOptions.macKeyboard, wired fromisApplePlatform()) keep Ctrl+C as the interrupt even over a selection. Cmd+C owns copy there and already works, and macOS browsers do not copy on Ctrl+C, so claiming it would swallow the key entirely.Tests
Ten new tests in
web/src/emulator/emulator.test.tscover the stand-aside, the clear-then-interrupt sequence, the empty-selection interrupt, the Mac gate, Cmd+C passthrough, both Ctrl+Shift+C paths including a refused clipboard write, and the Ctrl+Shift+V stand-aside. Full web suite: 1381 tests green,pnpm run lintclean.🤖 Generated with Claude Code