git-stats: make clicking a chip actually open the pull request - #24
Merged
Merged
Conversation
It never worked. The label was rendered as an OSC 8 hyperlink and the escape sequence really was in the output — I verified that much when building it, which is exactly why the bug survived: the link was present and unreachable. OpenCode's TUI holds any-event mouse tracking on (`?1000h ?1002h ?1003h ?1006h`, visible in a pty capture). Under mouse tracking the terminal forwards every click to the application and never activates a hyperlink itself, so the only way to follow one is the terminal's bypass modifier — which nobody is obliged to know. Verifying that the escape sequence was emitted was not the same as verifying a click did anything, and only the second claim was the one worth making. The click does reach the plugin, so the plugin opens the URL itself: `open` on macOS, `xdg-open` elsewhere, `cmd /c start "" <url>` on Windows. Spawned with an argv array, never a shell string, and gated to `http(s)` — chip URLs are already built from an allow-listed host, but this is the last point before a URL reaches the operating system. The OSC 8 link stays for anyone who does modifier-click. The `×` keeps its own handler on its own element, so dismissing does not also open a browser tab. Verified by driving a real terminal: with a stub `open` first on PATH, an SGR mouse click at the chip's coordinates records the PR URL, and a click on the `×` dismisses the chip while recording nothing. Also corrects the 0.1.1-beta.1 entry, which claimed the version was deprecated on npm. It is not — the registry still reports no deprecation — and a changelog that says otherwise is worse than one that says nothing.
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.
Reported: clicking a PR chip does nothing.
Why it never worked
The label was an OSC 8 hyperlink, and the escape sequence really was in the
output — I checked that when building it, which is precisely why the bug survived.
OpenCode's TUI holds any-event mouse tracking on. Straight from a pty capture:
Under mouse tracking the terminal forwards every click to the application and never
activates a hyperlink itself. The link was reachable only via the terminal's bypass
modifier, which nobody is obliged to know about.
Confirming the escape sequence was emitted is not the same as confirming a click
does something, and only the second claim was worth making.
Fix
The click reaches the plugin, so the plugin opens the URL:
openon macOS,xdg-openelsewhere,cmd /c start "" <url>on Windows. Spawned with an argvarray, never a shell string, and gated to
http(s)— chip URLs are already builtfrom an allow-listed host, but this is the last gate before a URL reaches the OS.
The OSC 8 link stays for anyone who does modifier-click.
The
×keeps its own handler on its own element, so dismissing a chip does notalso open a browser tab.
Verified in a real terminal
With a stub
openfirst onPATH, driving the actual TUI under a pty:\x1b[<0;105;15M) →OPENED: https://github.com/navbytes/opencode-plugins/pull/20×(\x1b[<0;114;15M) → noopencall, and the chip disappears from every subsequent screenPlus 12 new unit tests on the opener: per-platform argv, the empty title argument
cmd /c startneeds or it swallows the URL, and refusal offile:,javascript:,data:,ssh:and bare paths. 91 tests total, typecheck and build clean.Also
Corrects the
0.1.1-beta.1changelog entry, which claimed that version wasdeprecated on npm. It is not — the registry still reports no deprecation — and a
changelog that says otherwise is worse than one that says nothing.