Repository navigation
fix(terminal): keep a Ctrl+click wmux opens from reaching a mouse-tracking app (#353) - #354
Merged
amirlehmam merged 1 commit intoOct 25, 2026
Conversation
…cking app (amirlehmam#353) In a pane whose app has mouse tracking on, xterm reported a Ctrl+click on a link to the app while wmux opened the link, so an app that opens links on Ctrl+click opened it a second time in the system browser. Claim the press and release in the capture phase when a link is under the pointer, and open the link on the release.
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #353
In a pane whose app has turned on mouse tracking, a Ctrl+click on a link now opens it once, in wmux, and the app no longer sees the click. Before, xterm reported the Ctrl+click to the app while wmux opened the link, so an app that opens links on Ctrl+click (seen with Claude Code) opened a second copy in the system browser.
Cause
Since #280,
linkClickTargetgives a modified click in a mouse-tracking pane to wmux. But xterm's mousedown reporter only holds back a selection-forcing modifier (Shift, or Alt on macOS), so the press and release still reached the app with the Ctrl bit set (ESC[<16;…M/m).Design choices
hover/leavecallbacks. Both link sources (OSC 8linkHandlerandWebLinksAddon) share one hover state, since xterm's current link is private.Verification
Besides the unit tests, I loaded real xterm 6.0.0 in Electron 43 and sent trusted CDP mouse events, with and without the new listeners. Without them, Ctrl+click on a plain URL and on an OSC 8 link opened wmux and also sent the press/release to the app. With them, each opened wmux once and sent nothing to the app. Plain clicks and Ctrl+clicks off a link were still reported the same way in both runs.
I also ran this branch as a side-by-side dev instance (
WMUX_INSTANCE) and sent CDP mouse input to its window, with each link pointing at a local page that logs who loads it. When Claude Code 2.1.310 printed a link, Ctrl+click opened it once in the wmux panel and the system browser never requested it. A plain click opened nothing. In a small mouse-tracking test app, Ctrl+click on a link opened it and the app received no report. Plain clicks and Ctrl+clicks off the link still reached the app.