Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e4bf39e5584a482937da4019d5e7bc7a15822580
https://github.com/WebKit/WebKit/commit/e4bf39e5584a482937da4019d5e7bc7a15822580
Author: Chris Dumez <[email protected]>
Date: 2026-07-15 (Wed, 15 Jul 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/cdata-in-integration-point-fragment-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/cdata-in-integration-point-fragment.html
M Source/WebCore/html/parser/HTMLTreeBuilder.cpp
Log Message:
-----------
CDATA sections should be allowed at integration points during fragment parsing
https://bugs.webkit.org/show_bug.cgi?id=319474
Reviewed by Anne van Kesteren.
In 310593@main, constructTree() was updated to use the adjusted current node
(instead of the current node) for the integration point checks that compute the
tokenizer's shouldAllowCDATA and forceNullCharacterReplacement flags. That
change
correctly fixed a normal-vs-fragment-parsing inconsistency, but it preserved a
long-standing deviation from the specification: it kept both flags coupled to a
single "in foreign content" condition that excludes integration points.
Per the tokenizer's "markup declaration open state"
(https://html.spec.whatwg.org/multipage/parsing.html#markup-declaration-open-state),
CDATA sections are switched into whenever "there is an adjusted current node and
it is not an element in the HTML namespace". Integration points are NOT a
consideration there. Since integration points (MathML mi/mo/mn/ms/mtext and SVG
foreignObject/desc/title) are themselves in the MathML/SVG namespace, CDATA
sections should be allowed when the adjusted current node is an integration
point. This matches Firefox and Edge; Chrome and shipping Safari incorrectly
disallow CDATA there due to shared WebKit heritage. See the discussion in
whatwg/html#4016 (https://github.com/whatwg/html/issues/4016), where the spec
was
confirmed to intentionally key only off the adjusted current node's namespace.
The forceNullCharacterReplacement flag is different: it follows the tree
construction dispatcher's notion of foreign content
(https://html.spec.whatwg.org/multipage/parsing.html#tree-construction), which
treats integration points as HTML content and thus must continue to exclude
them.
This patch decouples the two flags so each matches its respective specification:
shouldAllowCDATA now depends only on whether the adjusted current node is in a
non-HTML namespace, while forceNullCharacterReplacement retains the integration
point exclusions.
The web platform test added in 310593@main asserted the previous (incorrect)
behavior and failed in spec-compliant Firefox; it has been updated to assert
that
CDATA is allowed at integration points, with an HTML context element added as a
control for the disallowed case.
No new tests, updated existing test.
*
LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/cdata-in-integration-point-fragment-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/cdata-in-integration-point-fragment.html:
* Source/WebCore/html/parser/HTMLTreeBuilder.cpp:
(WebCore::HTMLTreeBuilder::constructTree):
Canonical link: https://commits.webkit.org/317273@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
