Handle NodeIterator node removal during filtering#1479
Merged
Conversation
The traverse algorithm read the reference into local variables, ran the filter (which can execute author code), and then wrote those locals back. Filtering can remove nodes and run the NodeIterator pre-remove steps, but those adjusted only the stored reference, not the in-progress traversal position held in traverse's locals. As a result a node removed during its own filtering could leave the reference pointing at a detached node, and traversal could continue from there. Model a reference as a node pointer (a tuple of a node and a pointer before), and give each NodeIterator a candidate node pointer that holds the in-progress traversal position. traverse advances the candidate, sets the reference to it only once a node is accepted, and returns the node passed to the filter. The pre-remove steps adjust both the reference and, while traversing, the candidate. referenceNode continues to report the last accepted node during filtering. Matches Gecko, Blink, and WebKit (originally found via Acid3). Tests: web-platform-tests/wpt#61035
shannonbooth
reviewed
Jul 2, 2026
| <ol> | ||
| <li><p>If <var>toBeRemovedNode</var> is not an <a for=tree>inclusive ancestor</a> of | ||
| <var>nodeIterator</var>'s <a for=NodeIterator>reference</a>, or <var>toBeRemovedNode</var> is an | ||
| <var>nodePointer</var>'s <a for="node pointer">node</a>, or <var>toBeRemovedNode</var> is an |
Member
There was a problem hiding this comment.
This is the same approach ladybird does to fix this scenario (factored slightly differently, but I think this is nicer). I don't have any ideas for a less invasive approach.
Though the thing I noticed adjusting the implementation to match this exactly is if I understand correctly, I think nodePointer needs to be defined as a variable here from nodeIterator since it's not passed through in "given"
Member
Author
There was a problem hiding this comment.
I'm not sure I fully understand what you meant, but I made it more explicitly a variable of adjust. Does that help?
Member
There was a problem hiding this comment.
Yup, sorry for being unclear thats what I meant
Per review: the node pointer being adjusted was dangling off the operation name rather than declared as an input, unlike e.g. clone a single node. Move it into the given clause.
shannonbooth
added a commit
to shannonbooth/ladybird
that referenced
this pull request
Jul 3, 2026
Align NodeIterator with the current DOM spec traversal and pre-removal algorithms. The spec now covers the cases we were previously working around to match the behaviour of other engines. The algorithm we had implemented to protect against removal during filtering matches the spec algorithm quite closely, with slightly different factoring. See: * whatwg/dom#1479 * whatwg/dom#1477 This fixes the case where removing an ancestor of the reference or candidate reference, with the pointer before it and no following node inside the root, should retarget to the previous in-tree node instead of leaving the iterator on a detached node.
shannonbooth
added a commit
to LadybirdBrowser/ladybird
that referenced
this pull request
Jul 3, 2026
Align NodeIterator with the current DOM spec traversal and pre-removal algorithms. The spec now covers the cases we were previously working around to match the behaviour of other engines. The algorithm we had implemented to protect against removal during filtering matches the spec algorithm quite closely, with slightly different factoring. See: * whatwg/dom#1479 * whatwg/dom#1477 This fixes the case where removing an ancestor of the reference or candidate reference, with the pointer before it and no following node inside the root, should retarget to the previous in-tree node instead of leaving the iterator on a detached node.
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.
The
NodeIteratortraversealgorithm read the reference into local variables, ran the filter (which can execute author code), and then wrote those locals back. Filtering can remove nodes and run theNodeIteratorpre-remove steps, but those adjusted only the stored reference, not the in-progress traversal position held intraverse's locals. As a result a node removed during its own filtering could leave the reference pointing at a detached node, and traversal could continue from there.This models a reference as a node pointer (a tuple of a node and a pointer before) and gives each
NodeIteratora candidate reference node pointer that holds the in-progress traversal position.traverseadvances the candidate reference, sets the reference to it only once a node is accepted, and returns the node passed to the filter. The pre-remove steps adjust both the reference and, while traversing, the candidate reference.referenceNodecontinues to report the last accepted node during filtering.Matches Gecko, Blink, and WebKit (originally found via Acid3).
Tests: web-platform-tests/wpt#61035
Preview | Diff