fix: let a drag on a diff select text - #68
Merged
Merged
Conversation
Targeting ran on mousedown and pulled focus into the composer on mouseup, so a drag across diff lines was consumed as a line range and the text selection it made was gone before it could be copied. Reading a diff means taking lines out of it, so the pointer's own gesture for that has to keep working. Targeting now runs on mouseup and bails when the selection it finds is not collapsed -- the rule the Markdown page has followed all along. Ranges are made by click and Shift+click, which initializeDiffLines already implemented, so nothing is lost by handing the drag back. The mouseover that extended a range while the button was down is gone with it. Shift+click is the exception the rule has to make: the browser extends its own text selection on the way there, and the handler drops that selection before taking the range, because Shift+click is the range gesture and a stray highlight is not what was asked for. The line number and marker columns are already user-select: none, so what lands on the clipboard is the code alone. Verified in headless Chrome over CDP, clipboard included: a drag across four lines whose markers read " ", " ", "-", "-" copies neither the markers nor the numbers. User request: diff review 時に document column に表示されている diff の内容をクリップボードにコピーできるようにしたい。 現在はドラッグで範囲選択すると即座に composer がアクティブになり選択状態を維持できず、コピーができない。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
UI_DESIGN 5.2 said "drag or shift-click selects a range" and explained the mouseup focus as a way to keep click-drag text selection alive. Both describe the page as it was before the drag was handed back to the browser. It now says what the gesture split is and why it falls that way, keeps the two alternatives that were turned down -- Option+drag, and telling the two apart by how far the drag travelled -- and notes what the user-select: none on the number and marker columns buys: the clipboard gets the code alone, and a drag that starts on a number selects nothing. User request: 変更に合わせてドキュメントを追随させる。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
handlename
force-pushed
the
fix/copy-on-diff
branch
from
August 29, 2026 14:03
754b86b to
c4a2b39
Compare
Merged
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
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.
Why this change is necessary
A diff is read by taking lines out of it — into an editor, a terminal, a chat message. On the diff review page that was impossible: dragging across diff lines was consumed as a comment line range, and the composer took focus on mouse-up, so whatever text the drag had selected was gone before it could be copied. There was no other way to get the text out either, short of opening the file the diff came from.
Approach
The drag goes back to the browser. Targeting now runs on
mouseupand bails when the selection it finds is not collapsed — the rule the Markdown page has followed all along, so the two review modes now answer the pointer the same way. Comment ranges are made by click and Shift+click, whichinitializeDiffLinesalready implemented, so handing the drag back costs nothing.Shift+click is the exception that rule has to make. The browser extends its own text selection on the way there, and the handler drops that selection before taking the range, because Shift+click is the range gesture and a stray highlight left behind is not what was asked for.
The line number and marker columns are already
user-select: none, so what lands on the clipboard is the code alone — no line numbers, no+/-. Nothing had to change for that.Two alternatives were turned down, and
UI_DESIGN.md§5.2 records why: putting text selection behindOption+drag, which preserves every existing habit but hides copying — the more frequent act — behind a modifier no one would guess; and telling the two gestures apart by how far the drag travelled, which has no honest boundary and would flip meaning mid-gesture.Design Documents
UI_DESIGN.md§5.2 is the design record for this change, and it is updated in this PR rather than kept separately.Review Points
dragFrombecametargetFrom. It is no longer where a drag started; it is the line a Shift+click extends the range from.UI_DESIGN.mdalready notes there is no browser test harness here, so this was checked in headless Chrome over CDP: 18 assertions covering drag-to-select, click targeting, Shift+click ranges, file-header drag and click, and the Quote Lines button — plus the whole clipboard path, where a drag across four lines whose markers read" "," ","-","-"copies neither the markers nor the numbers.