fix(html): a pdf's selection shows the text it marks - #916
Merged
Merged
Conversation
v7.2.0 gave the `::selection` rules a background, because an author rule drops the UA's own and the selection painted nothing. That background is `Highlight`, which is opaque, and the layer carrying it paints over the glyph layer - so selecting a word hid it. It is see-through now: a `color-mix` of the platform's highlight, over an rgba fallback for an engine that cannot parse one. Checked on the reported document in chrome 153 and in an android WebView on chrome 91, where the fallback is what paints. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJJdfqpnVCKBNHXjAVxSou
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.
v7.2.0 gave the
::selectionrules a background, because an author::selectiondrops the UA's own and the selection was painting nothing. The background it states isHighlight, andHighlightis opaque - while the layer carrying it,.sel, comes after.visin the page and therefore paints over the glyphs. So a reader who selected a word saw the word disappear behind its own highlight.Reported from the device, and reproduced: the selected "Hough" is a blank blue box.
The background is see-through now. Two declarations, the second winning where it parses:
so a current engine follows the platform's own highlight colour, and an older one still gets a sane translucent blue rather than nothing.
Checked
The real document this was reported on, rendered by
cli/translateand selected in both engines:::selectionbackground resolves tocolor(srgb 0.502 0.737 0.996 / 0.27)rgbafallbackNothing renders differently outside a selection, so the reference output is unchanged.