fix(html): a selection's end keeps its handle in a pdf view - #917
Merged
Merged
Conversation
The selection layer's runs were scroll containers, so a system font wider than the pdf advance was clipped. A webview draws no handle for an end it cannot see, so marking such a run left one handle, and the mark could not be adjusted from that side. Nothing clips a run now. The spill is invisible text either way - the layer's color is transparent. The clip did carry the y alignment, because an inline-block baseline-aligns on its bottom margin edge only when it is a scroll container, so `vertical-align:bottom` states that alignment instead: the strut is zero-height and sits on the baseline, so a run's bottom edge lands there whatever the run's height. Measured on a Pixel 9 Pro, over the reported document: every run of the page sits where the clipped rule put it, to the pixel. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJJdfqpnVCKBNHXjAVxSou
andiwand
force-pushed
the
fix/a-selection-end-keeps-its-handle
branch
from
September 20, 2026 14:41
bff0097 to
0234031
Compare
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.
Marking text in a pdf left the selection one handle, so the mark could not be adjusted from that side.
Why
The selection layer's runs (
.sr) carriedoverflow:hidden, which makes them scroll containers. A run's box is the pdf's own advance, and the substitute system font is often wider than it, so the text spilled and was clipped. Measured on the reported document:scrollWidth71 againstclientWidth64, and the selection rectangle ended at x=339 while the run's box ended at x=334. A webview draws no handle for an end it cannot see.Overriding
overflow:visiblelive on the device brought the second handle back, which is what pointed at the clip.The catch, and what it costs
The clip was also carrying the y alignment: an inline-block baseline-aligns on its bottom margin edge only while it is a scroll container. Dropping the clip alone moved every run down - measured on the device,
126.9becoming130.5- which would slide the invisible layer off the glyphs it has to sit on.overflow:clipdoes not help: it is not a scroll container either, so it aligns likevisiblewhile still clipping.So the alignment is now stated rather than inherited.
.tsetsfont-size:0, so the strut is zero-height and sits on the baseline; withvertical-align:bottomevery run's bottom edge lands on that baseline, whatever the run's height - which is what the bottom margin edge was doing..sg, the gap spacer, keeps its clip: it holds a space, so no handle can land in it.Checked
On a Pixel 9 Pro, over the reported document, with the two rules swapped on the same live page: all 23 runs of the page sit at the same position to the pixel (
maxDelta: 0).