Add test cases for null registry element upon adoption by ja-y-son · Pull Request #56423 · web-platform-tests/wpt

ja-y-son · 2025-12-02T16:40:30Z

Add test cases that covers the scenarios in whatwg/dom#1437

ja-y-son · 2025-12-04T02:56:55Z

@annevk PTAL, thanks!

annevk

I think we should have some tests where you just call adoptNode(). And some tests with attachShadow() instead of declarative shadow roots.

And some tests where we initialize() various parent nodes in this null/global shadow tree with a scoped registry prior to adoption.

ja-y-son · 2025-12-11T18:18:01Z

Added more test cases to hopefully cover most of the adoption cases that we're interested in this spec change. I haven't implemented this part of spec change in chromium so I tried my best to verify that each test case is asserting the correct expectation, but will appreciate a lot for another review of them.

annevk

This generally looks good. I'd like to try this in WebKit, but the patch needs rebasing it seems.

cc @rniwa

annevk · 2025-12-16T13:50:45Z

+
+function runTest(operation, operationName) {
+    // Null registry child tests
+    test((test) => {


Optional nit (applies quite a few times):

Suggested change

test((test) => {

test(test => {

ja-y-son · 2026-01-04T03:36:01Z

@annevk Updated the nit. Let me know if you've tried on Safari and if you think we should make any other changes on the PR

annevk · 2026-01-07T16:14:30Z

Still has many lint errors that need to be fixed. Please make sure CI is green.

ja-y-son · 2026-01-08T07:27:14Z

Thanks for the heads up! Fixed rest of the nit

annevk · 2026-01-13T10:53:30Z

It seems this has a merge conflict now. Can you address it? I'll also ping @rniwa again as I'd really like him to take a look as well.

rniwa · 2026-01-20T10:42:41Z

+    const [doc, win] = makeIframe(t);
+    doc.body.append(clone);
+    const host2shadow = doc.querySelector('#template-host-2').shadowRoot;
+    assert_equals(host2shadow.querySelector('new-foo').customElementRegistry, null);


I don't understand why we expect the registry of new-foo to be null here. When we're adopting this element in append, inclusiveDescendant is an element, and its custom element registry is null at that point. In step 3.1.3.2.2, inclusiveDescendant's custom element registry is null and the parent isn't null (it's a ShadowRoot) or an exclusive DocumentFragment node so we move onto step 3.1.3.2.3. Step 3.1.3.2.3 says we set the registry to the result of looking up a custom element registry given inclusiveDescendant's parent. Here, inclusiveDescendant's parent is a ShadowRoot which is a clone of a ShadowRoot which had been initialized in line 175 of this test. So far as I can tell, customElementRegistry shouldn't be null here.

Correct that new-foo has parents that have valid scoped custom element registry. At the same time in step 3.1.3.2.4, it outlines that the registry we should set to the inclusiveDescendant is the effective global custom element registry of that registry from the parent. Given the parent's registry's is scoped is true, we will end up setting a null registry to new-foo

rniwa · 2026-01-20T19:52:38Z

+    // Null registry child tests
+    test(test => {
+        const [win, host] = operation(addNullRegistryChild(createParentElementWithRegistryAttribute(null)), test);
+        assert_equals(host.querySelector('a-b').customElementRegistry, null);


I don't understand why this case uses null registry either. When appendToNewDocument is called, we're appending the parent div without customelementregistry, meaning its registry is not null (uses the global registry) along with its descendants, the first of which has customelementregistry specified and uses null registry. However, step 3.1.3.3 of adopting a node says to lookup the custom element registry given its parent, which is the parent div that uses a global registry. Step 3.1.3.4 sets the registry of the inner div (one with customelementregistry) to this global registry as well.

We were going to include this spec change in whatwg/dom#1437 but decided to leave it to whatwg/html#12000 as its related to the element attribute. But essentially, we're planning to have a similar concept to shadowrootcustomelementregistry of "keep custom element registry null", so in this case the element with the attribute will remain to have null registry upon adoption. I can add these tests related to element attribute back later if this seems too confusing.

rniwa · 2026-01-21T09:58:23Z

+    doc.body.append(clone);
+    const host1shadow = doc.querySelector('#template-host-1').shadowRoot;
+    assert_equals(host1shadow.querySelector('x-foo').customElementRegistry, win.customElements);
+    assert_true(host1shadow.querySelector('x-foo') instanceof XFoo);


This will always fail because XFoo extends the outer document's HTMLElement so the HTMLElement constructor will throw upon an upgrade attempt. Each one of these test cases that use XFoo in an iframe should define its own class which extends iframe's HTMLElement.

Here's a simple HTML which demonstrates that the constructor extending HTMLElement in the outer document is problematic:

<!DOCTYPE html> <html> <body> <script> class CustomElement extends HTMLElement { }; const iframe = document.createElement('iframe'); document.body.appendChild(iframe); iframe.contentWindow.customElements.define('custom-element', CustomElement); iframe.contentDocument.body.innerHTML = '<custom-element></custom-element>'; </script> </body> </html>

Thanks for catching this! Will fix the issue.

rniwa · 2026-01-21T11:21:34Z

+
+    test(test => {
+        const [win, host] = operation(addScopedRegistryChild(createParentDeclarativeShadowRootWithRegistryAttribute(scopedRegistry)), test);
+        assert_equals(host.shadowRoot.querySelector('a-b').customElementRegistry, scopedRegistry);


I don't think this expected behavior is correct. createParentDeclarativeShadowRootWithRegistryAttribute calls initialize but only after having inserted the cloned subtree into iframe's document. Because adopting a node sets the registry of the shadow root and initialize only sets the registry when the current value is null, initialize will have no effect on the subtree.

createParentDeclarativeShadowRootWithRegistryAttribute actually does not insert the cloned subtree into an iframe's document, but just an outer document, and since appending within the same document does not give the shadowroot a non-null registry, running initialize should be effective on setting registry on the given shadow root.

rniwa · 2026-01-22T00:05:10Z

There could be issues with other test cases but can we tackle the above issues first?

ja-y-son · 2026-02-11T21:04:19Z

@rniwa @annevk Gentle ping on this PR as I'd like to conclude changes here before we keep working on whatwg/html#12000

ja-y-son mentioned this pull request Dec 2, 2025

Update element adoption logic for scoped registry whatwg/dom#1437

Open

5 tasks

moz-wptsync-bot added the mozilla:gecko-blocked label Dec 2, 2025

ja-y-son marked this pull request as ready for review December 4, 2025 02:56

wpt-pr-bot added custom-elements wg-webplatform labels Dec 4, 2025

wpt-pr-bot assigned kojiishi Dec 4, 2025

wpt-pr-bot requested review from TakayoshiKochi, hayatoito, kojiishi, rniwa and snuggs December 4, 2025 02:56

annevk reviewed Dec 8, 2025

View reviewed changes

annevk reviewed Dec 16, 2025

View reviewed changes

ja-y-son force-pushed the adopt-update branch from e11725c to 242f82e Compare January 4, 2026 03:34

Jayson Chen added 5 commits January 13, 2026 10:31

Add test cases for null registry element upon adoption

a1dd169

Add test cases to append-does-not-upgrade file and update file name

d0c7b84

Add more coverage

1250f9e

Small nit

2eb4c86

Fix the rest of nits

c701183

ja-y-son force-pushed the adopt-update branch from c57a2b0 to c701183 Compare January 13, 2026 18:33

ja-y-son mentioned this pull request Jan 14, 2026

Include cloning keep custom element registry null while cloning shadow root whatwg/dom#1445

Merged

5 tasks

rniwa reviewed Jan 20, 2026

View reviewed changes

rniwa reviewed Jan 21, 2026

View reviewed changes

ja-y-son requested review from annevk and rniwa February 11, 2026 21:02

Conversation

ja-y-son commented Dec 2, 2025

Uh oh!

ja-y-son commented Dec 4, 2025

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

ja-y-son commented Dec 11, 2025

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ja-y-son commented Jan 4, 2026

Uh oh!

annevk commented Jan 7, 2026

Uh oh!

ja-y-son commented Jan 8, 2026

Uh oh!

annevk commented Jan 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rniwa commented Jan 22, 2026

Uh oh!

ja-y-son commented Feb 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants