Update element adoption logic for scoped registry #1437

ja-y-son · 2025-12-02T07:43:54Z

Fixing #1429 to make sure element is getting the correct scoped custom element registry upon adoption. This PR also includes the concept that will be defined in whatwg/html#12000 (keep custom element registry null).

At least two implementers are interested (and none opposed):
- Webkit
- Chromium
Tests are written and can be reviewed and commented upon at:
- Add test cases for null registry element upon adoption web-platform-tests/wpt#56423
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/issues/399124619
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1874414
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=302970
MDN issue is filed: N/A
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

Preview | Diff

dom.bs

annevk · 2025-12-02T09:23:33Z

dom.bs

+         <a for=Element>custom element registry</a> is null or is equal to <var>document</var>'s
+         <a>effective global custom element registry</a>, then set <var>inclusiveDescendant</var>'s
+         <a for=Element>custom element registry</a> to <var>inclusiveDescendant</var>'s
+         <a for=tree>parent</a>'s <a for=Element>custom element registry</a>.


Why is this not using the "effective global custom element registry" strategy discussed? It's not clear to me this is the same or why we need to be looking at document at all.

Updated to use "effective global custom element registry" strategy as discussed. Was trying to see if I could get the point across with another approach but it seems like "effective global custom element registry" is still the better way to go. Lmk if I'm missing anything on this idea.

dom.bs

annevk

This looks good to me. We'll need tests next.

For the tests I'd like us to exercise some of the more complicated scenarios with some nodes having been assigned registries and others not, etc.

dom.bs

ja-y-son · 2025-12-02T16:43:28Z

Just added some tests but I haven't fully verified them yet. Feel free to take a look.

dom.bs

ja-y-son · 2025-12-04T03:21:55Z

@annevk Want to verify that this is the expected behavior from this change on effective gloabl registry. Consider this test case from adoption.window.js

test(t => {
  const contentDocument = document.body.appendChild(document.createElement('iframe')).contentDocument;
  t.add_cleanup(() => contentDocument.defaultView.frameElement.remove());
  const element = document.createElement('div');
  assert_equals(element.customElementRegistry, customElements);

  const scoped = new CustomElementRegistry();
  const scopedElement = contentDocument.createElement('div', { customElementRegistry: scoped });
  contentDocument.body.appendChild(scopedElement);
  assert_equals(scopedElement.customElementRegistry, scoped);
  scopedElement.appendChild(element);
  assert_equals(element.customElementRegistry, contentDocument.customElementRegistry);
}, "Adoption with global registry into a scoped registry");

Given that now we look at the parent's registry's effective global registry, the last assert of the test should probably be

assert_equals(element.customElementRegistry, null);

given that the parent is using a scoped registry.
Is this expected? Or we want it to keep getting global registry for this element? It feels a bit odd that it originally has a global registry but after adoption it goes to null registry. Perhaps we should make sure that non-null registry element shouldn't get null registry after adoption (unless there are no global registry available)?

annevk · 2025-12-04T06:21:23Z

Yeah, I suppose distinguishing those cases would be better. I doubt anyone is going to run into this in practice, but we might as well make it nice.

annevk · 2025-12-05T10:45:44Z

dom.bs

+         <li>
+          <p>Otherwise, set <var>registry</var> to the
+          <a>effective global custom element registry</a> of the result of
+          <a for=/>looking up a custom element registry</a> given <var>inclusiveDescendant</var>'s
+          <a for=tree>parent</a>.
+
+          <ol>
+           <li><p>If <var>inclusiveDescendant</var>'s <a for=Element>custom element registry</a> is
+           non-null and <var>registry</var> is null, set <var>registry</var> to
+           <var>document</var>'s <a for=Document>custom element registry</a>'s
+           <a>effective global custom element registry</a>.
+          </ol>


I don't understand this. If you mean for this to only apply in the Otherwise branch you need to nest the first bit of the Otherwise branch as well.

ja-y-son · 2025-12-05T14:13:35Z

I think I made it unnecessarily complicated in the previous iteration. Given that our main goal is that global registry element shouldn't become null registry during adoption, I think we can simply include this category (global registry) to use document's registry's effective global registry, so it wouldn't be getting null from parent. Does this make sense? Or perhaps I'm missing something here.

annevk

Yeah I think this works. I'll re-review on Monday to be sure. If @sorvell, @rniwa, and maybe @keithamus could have a look as well that'd be great.

(Checking inclusiveDescendant's custom element registry again bothers me a little bit, but I don't see a good way out of that. I also want to double check the "DocumentFragment but not ShadowRoot" language.)

dom.bs

Co-authored-by: Anne van Kesteren <annevk@annevk.nl>

ja-y-son · 2026-01-04T04:00:42Z

@annevk Went through this PR again and I think it still works. Do we want to merge this PR first while wrapping up web-platform-tests/wpt#56423

annevk · 2026-01-07T13:42:43Z

dom.bs


   <li><p>If <var>registry</var> <a>is a global custom element registry</a>, then set
-   <var>registry</var> to <var>document</var>'s <a>effective global custom element registry</a>.
+   <var>registry</var> to <var>document</var>'s <a for=Document>custom element registry</a>


Suggested change

<var>registry</var> to <var>document</var>'s <a for=Document>custom element registry</a>

<var>registry</var> to <var>document</var>'s <a for=Document>custom element registry</a>'s

(might have to rewrap)

annevk · 2026-01-07T13:43:59Z

dom.bs

+         <li><p>If <var>inclusiveDescendant</var>'s <a for=Element>custom element registry</a> is
+         non-null, <var>inclusiveDescendant</var>'s <a for=tree>parent</a> is null, or
+         <var>inclusiveDescendant</var>'s <a for=tree>parent</a> is a {{DocumentFragment}} but not
+         a {{ShadowRoot}}, then set <var>registry</var> to <var>document</var>'s


Suggested change

a {{ShadowRoot}}, then set <var>registry</var> to <var>document</var>'s

a {{ShadowRoot}} <a for=/>node</a>, then set <var>registry</var> to <var>document</var>'s

I might actually want to define exclusive DocumentFragment for this. Similar to what we have for Text nodes.

Could you elaborate on what you meant by define exclusive DocumentFragment?

I'm happy to take care of that but if you want to take a stab at it you'd have to define something equivalent to https://dom.spec.whatwg.org/#exclusive-text-node for DocumentFragment.

I added the definition for exclusive document fragment. Let me know if I captured what you thought correctly.

annevk · 2026-01-07T13:46:16Z

dom.bs

 <dt><dfn export for=Element>custom element registry</dfn>
 <dd>Null or a {{CustomElementRegistry}} object.

+ <dt><dfn export id=concept-element-keep-custom-elemenet-registry-null for=Element>keep custom element registry null</dfn>


Suggested change

<dt><dfn export id=concept-element-keep-custom-elemenet-registry-null for=Element>keep custom element registry null</dfn>

<dt><dfn export for=Element>keep custom element registry null</dfn>

We don't do hardcoded IDs for new concepts. Use the generated ID.

annevk · 2026-01-07T15:20:37Z

Also, now that "keep custom element registry null" is part of this PR, it depends on whatwg/html#12000 so we should mention that in the commit message and get that PR finished as well.

ja-y-son · 2026-01-08T07:39:18Z

I updated the commit message so it mentions the new concept that will be defined in whatwg/html#12000. I'll prioritize getting this adoption logic PR landed and will for sure get the attribute PR finished next. Let me know if you prefer me to take "keep custom elemetn registry null" idea out of this PR for now; I can also land this PR without the concept and put it together with attribute PR.

annevk · 2026-01-08T08:51:34Z

Let's keep it out of this PR then.

Modify element adoption SCER

cfc5109

annevk reviewed Dec 2, 2025

View reviewed changes

Use effective global custom element registry as discussed

1dc85e4

annevk reviewed Dec 2, 2025

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

Update steps

697020b

annevk approved these changes Dec 2, 2025

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

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

Add test cases for null registry element upon adoption web-platform-tests/wpt#56423

Open

Fix indentation

ee404fe

annevk reviewed Dec 2, 2025

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

Fix fix indentation

a334c2a

annevk reviewed Dec 5, 2025

View reviewed changes

simply logic

90fc49c

ja-y-son force-pushed the scer-element-adopt branch from 4b9862b to 90fc49c Compare December 5, 2025 14:10

annevk approved these changes Dec 5, 2025

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

ja-y-son and others added 2 commits December 7, 2025 20:03

Update dom.bs

79b21f3

Co-authored-by: Anne van Kesteren <annevk@annevk.nl>

Update build.yml

fdf7749

annevk mentioned this pull request Dec 8, 2025

Update GitHub Actions whatwg/spec-factory#81

Merged

Add element's keep custom element registry null concept

cb655e4

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

Introduce customelementregistry global attribute whatwg/html#12000

Open

6 tasks

annevk mentioned this pull request Dec 16, 2025

Implementations do not match spec behavior for .adoptNode(attr) #1440

Open

annevk reviewed Jan 7, 2026

View reviewed changes

Address comments

7e87fef

	<var>registry</var> to <var>document</var>'s <a for=Document>custom element registry</a>
	<var>registry</var> to <var>document</var>'s <a for=Document>custom element registry</a>'s

	a {{ShadowRoot}}, then set <var>registry</var> to <var>document</var>'s
	a {{ShadowRoot}} <a for=/>node</a>, then set <var>registry</var> to <var>document</var>'s

	<dt><dfn export id=concept-element-keep-custom-elemenet-registry-null for=Element>keep custom element registry null</dfn>
	<dt><dfn export for=Element>keep custom element registry null</dfn>

Update element adoption logic for scoped registry #1437

Are you sure you want to change the base?

Update element adoption logic for scoped registry #1437

Conversation

ja-y-son commented Dec 2, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

annevk left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ja-y-son commented Dec 2, 2025

Uh oh!

Uh oh!

ja-y-son commented Dec 4, 2025

Uh oh!

annevk commented Dec 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ja-y-son commented Dec 5, 2025

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ja-y-son commented Jan 4, 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!

annevk commented Jan 7, 2026

Uh oh!

ja-y-son commented Jan 8, 2026

Uh oh!

annevk commented Jan 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

ja-y-son commented Dec 2, 2025 •

edited by pr-preview bot

Loading

annevk left a comment •

edited

Loading