FFFF bug: Ctrl+click on a link in a mouse-tracking pane opens it in both the wmux panel and the system browser · Issue #353 · amirlehmam/wmux · GitHub
[go: up one dir, main page]

Skip to content

bug: Ctrl+click on a link in a mouse-tracking pane opens it in both the wmux panel and the system browser #353

Closed

Description

@jpstratman

Summary

In a pane where the running program has turned on mouse tracking (for example Claude Code's full-screen UI), Ctrl+click on a link opens it twice: once in the wmux browser panel and once in the system browser.

Steps to reproduce

  1. Run Claude Code in a wmux terminal pane (native Windows shell, wmux 2.40.0).
  2. Get it to print a link.
  3. Click the link: nothing happens. That part is expected since bug: one click on a link in an OpenCode v2 pane opens both the system browser and the wmux panel #280, because the plain click belongs to the app.
  4. Ctrl+click the link.

Expected: the link opens once, in the wmux browser panel (the default destination).

Actual: the link opens in the wmux browser panel and in the system default browser.

Cause

Since #280, linkClickTarget in src/renderer/utils/terminal-links.ts treats Ctrl+click in a mouse-tracking pane as wmux's, and wmux opens the link. But xterm still reports that Ctrl+click to the app. xterm's always-on mousedown listener in CoreBrowserTerminal._bindMouse only skips reporting when shouldForceSelection is true (Shift, or Alt on macOS), and the report includes the Ctrl modifier. An app that opens links on Ctrl+click then opens the same URL itself, in the system browser.

This is the same "two openers, neither can see the other" problem as #280, moved from the plain click to the modified click. #340's BROWSER routing does not cover it: it applies only to WSL panes, and the app opens the link itself on the click, not through wmux.

Proposed fix

When wmux takes a Ctrl/Cmd+click on a link in a mouse-tracking pane, it should not report that click to the app. A capture-phase mousedown/mouseup listener on the terminal container can stop the event before xterm's reporter sees it, but only when a link is under the pointer (tracked with the link providers' hover/leave callbacks), and then activate the link itself. Plain clicks, clicks that are not on a link, and panes without mouse tracking are unchanged.

Activity

  1. < 6CAD div class="timelineBodyContent__Uq4b9L">added a commit that references this issue on Oct 25, 2026
  • amirlehmam commented on Oct 25, 2026

    @amirlehmam
    Owner

    Shipped in v2.41.0.

  • Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      No labels
      No labels

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        0