fix: do not let a foreign end tag close an HTML element#1790
Open
spokodev wants to merge 1 commit into
Open
Conversation
The "any other end tag" rule for the in-body insertion mode (WHATWG 13.2.6.4.7, step 3) only matches an open node that is an HTML element. genericEndTagInBody matched an open element by tag id alone, so a foreign integration-point element (desc, title, mi, mo, mn, ms, mtext, annotation-xml) whose lowercase name collides with an HTML tag id was wrongly matched, closing an open HTML formatting element that should stay open. Add a namespace check to the match condition so a foreign element falls through to the namespace-aware special-element check and the end tag is ignored, as required by step 4. Browser-confirmed: `<svg><desc><b>x</desc>y` keeps <b> open so its text is "xy", not "x".
43081j
reviewed
Jul 8, 2026
| expect(onParseError).not.toHaveBeenCalled(); | ||
| }); | ||
|
|
||
| it('Regression - foreign end tag must not close an HTML element with a colliding tag id', () => { |
Collaborator
There was a problem hiding this comment.
Suggested change
| it('Regression - foreign end tag must not close an HTML element with a colliding tag id', () => { | |
| it('end tag in body must not match a foreign element with the same tag ID', () => { |
this isn't really a regression since it was never covered, even by the html5lib-tests it seems 😬
also its not that the end tag is foreign, its the reverse. the start tag is foreign and the end tag shouldn't close it
on a side note: this really belongs in html5lib-tests, but its fine here for now i think. maybe lets add a TODO
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 "any other end tag" rule for the in-body insertion mode (WHATWG 13.2.6.4.7, step 3) only matches an open node that is an HTML element; anything else falls through to step 4 (special element check, then ignore).
genericEndTagInBodymatched an open element by tag id alone, without checking its namespace. A foreign integration-point element (desc,title,mi,mo,mn,ms,mtext,annotation-xml) whose lowercase name collides with an HTML tag id was therefore wrongly matched, closing an open HTML formatting element that should stay open.Repro
The foreign
<svg desc>end tag</desc>must not close the open<b>, so<b>stays open and collects the trailing text. Browser-confirmed correct output:Before this fix parse5 produced
b.text = "x"(the<b>was wrongly closed and"y"leaked out as a sibling); the correct result isb.text = "xy".Fix
Add
p.treeAdapter.getNamespaceURI(element) === NS.HTMLto the match condition (NSis already imported) so a foreign element falls through to the namespace-aware_isSpecialElementcheck and the end tag is ignored, as the spec requires.Tests
Added a focused regression test in
packages/parse5/lib/parser/index.test.tsassertingb.text === "xy". It fails on the pristine source (expected "x" to be "xy") and passes with the fix. The full conformance suite stays green at 19,325 cases (unchanged).