Repository navigation
Conversation
…window clickedLink() required a fresh "cell" selection, so a re-click inside opentui's 500 ms double-click window (classified as "word") silently did nothing, and a pointer that crossed a cell boundary between press and release was treated as a drag selection even when it settled back on the link. Treat any gesture that starts and ends on the same cell as a click; gestures that end elsewhere stay selections, and triple clicks remain line selections.
github-actions
Bot
added
needs:compliance
Contributor
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
Contributor
|
The following comment was made by an LLM, it may be inaccurate: |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
The fix works. Running OpenCode from source with a simulated response that contains a link, a re-click within 150 ms of the previous click opened the link with this PR (3 opens) but not on the base (2 opens). The updated link.test.tsx passes here and fails against the base, and typecheck for packages/tui passes.
Public API: unchanged (the change is internal to the TUI's clickedLink).
Two non-blocking notes:
- The third and later clicks in a fast series are still
"line"selections, so they still do nothing. Hammering a link quickly therefore still drops most clicks, which is part of the problem the description lists. - #55661 moves this same gate into a shared
isPlainClick()inpackages/tui/src/ui/click.ts(keeping the oldisStart && behavior === "cell"check) and reuses it for prompt footer clicks. Whichever lands second will need to carry this logic over, either into that helper or kept specific to links if footer clicks should stay strict.
github-actions
Bot
removed
needs:compliance
Contributor
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
This branch has not been deployed
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.
Issue for this PR
Closes #56062
Type of change
What does this PR do?
clickedLink()required a fresh"cell"selection to treat a mouse release as a link click. That drops two ordinary gestures:"word"(further rapid clicks as"line"), becausenextClickBehavior()escalates clicks on the same renderable within 500 ms;isStartcleared, so the release reads as a drag even when it settles back on the link.Both feel like "the link only opens every other click" in daily use; rapid re-clicks are the worst case, since the click counter stays pinned at
"line".The fix treats a release as a click when the gesture started and ended on the same cell (
selection.anchorequalsselection.focus). Gestures ending on a different cell still count as selections, so drag selection and copy-on-select keep working. Triple clicks ("line") remain selections. Modified clicks are still left to the terminal.Trade-off: double-clicking link text now opens the link instead of word-selecting it. Word-selecting inside link text is still possible with a drag; the two gestures are indistinguishable at this layer, and the dropped re-click is the worse UX.
How did you verify your code works?
packages/tui/test/ui/link.test.tsxthat usesManualClock.setTime()to place a re-click deterministically inside the 500 ms window. It fails ondev(openedstays[url]) and passes with this change.bun test test/ui/inpackages/tui: 28 pass, 0 fail.Screenshots / recordings
Mouse behavior change in the terminal, nothing visible to screenshot.
Checklist