Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8b4bcb5752d08f72fca8ca9c4a44264b2faa6e4c
https://github.com/WebKit/WebKit/commit/8b4bcb5752d08f72fca8ca9c4a44264b2faa6e4c
Author: Ryosuke Niwa <[email protected]>
Date: 2026-07-14 (Tue, 14 Jul 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/custom-elements/registries/ShadowRoot-init-declarative-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/custom-elements/registries/element-mutation-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/custom-elements/registries/scoped-custom-element-registry-customelementregistry-attribute-expected.txt
M Source/WebCore/dom/Element.cpp
M Source/WebCore/html/parser/HTMLConstructionSite.cpp
Log Message:
-----------
[WPT] Various test cases in custom-elements/registries/element-mutation.html
fail
https://bugs.webkit.org/show_bug.cgi?id=319388
Reviewed by Chris Dumez.
The failure was caused by a built-in element (e.g. div) parsed inside an
declarative
shadow root with null registry (e.g. declared with
shadowrootcustomelementregistry
content attribute on template) not getting the usesNullCustomElementRegistry
flag -
only custom elements and unknown elements did (in HTMLConstructionSite's
createHTMLElementOrFindCustomElementInterface inside the "if (!element)" block).
The built-in element merely resolved to null via its tree scope.
That worked for the original (parsed before any global registry was ensured),
but
broke on cloning: once the global registry exists, cloning the subtree runs
Element::insertionSteps on the cloned nodes which pins the cloned element with
the global registry in the scoped map. Once pinned,
registry.initialize(shadowRoot)
could no longer hand it the scoped registry - hence the failures.
This PR applies two fixes to address the failures.
1. HTMLConstructionSite.cpp - set usesNullCustomElementRegistry on all elements
(built-in included) parsed inside a null-registry tree scope, so an element
behaves identically to its clones and keeps resolving to null across
mutations.
This unifies the previously separate custom-element and fragment-parsing
branches.
2. Element::attachShadow - an imperative attachShadow() with no explicit
registry
now always defaults to the document's registry, instead of null when the host
carries the null-registry flag. The host stays null; only the new shadow
root uses
the global registry.
(2) is required because (1) gives built-in elements the flag, and without it
their
attachShadow default would flip to null. As a bonus, it also fixes the
pre-existing
ShadowRoot-init-declarative.html custom-element FAIL, which failed for this
exact
reason.
Finally, this PR also addresses a bug that we weren't propagating the parent
node's
null-registry-ness to a child node during non-fragment parsing by generalizing
the condition (no longer checks m_isParsingFragment).
Test:
imported/w3c/web-platform-tests/custom-elements/registries/element-mutation.html
*
LayoutTests/imported/w3c/web-platform-tests/custom-elements/registries/ShadowRoot-init-declarative-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/custom-elements/registries/element-mutation-expected.txt:
* Source/WebCore/dom/Element.cpp:
* Source/WebCore/html/parser/HTMLConstructionSite.cpp:
(WebCore::HTMLConstructionSite::createHTMLElementOrFindCustomElementInterface):
Canonical link: https://commits.webkit.org/317215@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
