Text Fragments: Creating a text fragment inside a container that has ::before doesn't find other matches in that container
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox153 | --- | fixed |
People
(Reporter: jjaschke, Assigned: jjaschke)
Details
Attachments
(2 files)
STR: Open the attached example. Select the second "test", then open the context menu and click "Copy Link to Highlight".
Expected results: the created text fragment should be :~:text=foo-,test
Actual results: the created text fragment is :~:text=test, which also matches the first "test" inside the div.
Analysis:
nsFind uses ComparePoints() to figure out when it reached the end point. ComparePoints() does not work well with things like NAC or shadow DOM -- it will just return Some(1) in that case, which translates to "the NAC/Shadow DOM is after the node", which causes the Text Fragments algorithm to stop. Therefore it doesn't see the first "test" in the <div>, and the algorithm fails.
|
Assignee | |
Updated•21 days ago
|
|
|
Assignee | |
Comment 1•21 days ago
|
||
The endpoint check in nsFind uses ComparePoints to determine if
the current position is past the search boundary.
However, CompareClosestCommonAncestorChildren (used by ComparePoints)
returns Some(1) for NAC roots, incorrectly treating ::before content as
"after" regular children. This causes nsFind to exit early, missing
valid matches that follow the ::before in document order.
When the current node is in a native anonymous subtree and is not a
descendant of the endpoint container, use CompareTreePosition instead.
CompareTreePosition handles NAC correctly via GetIndexInParent, which
assigns proper indices to pseudo-elements matching the flat tree order.
|
||
Updated•8 days ago
|
|
||
Comment 3•7 days ago
|
||
| bugherder | ||
Description
•