Custom element registry handling on insert after adopt

[ja-y-son]

What is the issue with the DOM Standard?

While going through the WPT in adoption.window.js, there are some tests I'm having a hard time reasoning through with the logic outlined in spec. Specifically, I want to clarify the behavior of null registry handling on insert when a cross-document adoption happens.

Take "Adoption with explicit global registyr into a scoped registry (scoped registry target)" test case for example,

test(t => {
  const documentRegistry = new CustomElementRegistry();
  const contentDocument = document.implementation.createHTMLDocument();
  documentRegistry.initialize(contentDocument);
  assert_equals(contentDocument.customElementRegistry, documentRegistry);

  const element = document.createElement('div', { customElementRegistry: customElements });
  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, null);
}, "Adoption with explicit global registry into a scoped registry (scoped registry target)");

My understanding of the goal in this test is that when element is appended in scopedElement, which is a cross document adoption, according to the adoption spec, in step 3-1-3-2, "If inclusiveDescendant’s custom element registry is a global custom element registry, then set inclusiveDescendant’s custom element registry to document’s effective global custom element registry.", which results in null in element.customElementRegistry.

However, given that appendChild/append also run insert steps, according to insert step spec, after the adoption happens in step 7-1, in step 7-7-3-1, "If inclusiveDescendant’s custom element registry is null, then set inclusiveDescendant’s custom element registry to the result of looking up a custom element registry given inclusiveDescendant’s parent.", wouldn't this step assign a registry (in this case scopedElement's registry) to element?

Not sure if I missed anything in my reasoning above, would like to get some clarification on the spec around this logic.

cc @annevk @rniwa

[annevk]

It seems this was overlooked in #1390. You should only be able to go from a global registry to another global registry (or null). So the test is correct.

[ja-y-son]

You should only be able to go from a global registry to another global registry (or null)

Is that limited to the specific operation (append)? Can the null registry element still be initialized later on to a different scoped registry by calling CustomElementRegistry.initialize?

[sorvell]

@annevk Currently both Chrome and Safari implementations seem to mutate a null registry on adoption (example). That doesn't seem to match what you stated above. Is that intended?

Ideally it would not mutate in that case as implicit registry mutation can be very confusing, and this behavior was added for backwards compatibility which is not relevant here.

Code from example linked above:

const documentRegistry = new CustomElementRegistry();
const contentDocument = document.implementation.createHTMLDocument();
documentRegistry.initialize(contentDocument);
contentDocument.body.setHTMLUnsafe(`<div>
  <template shadowrootmode="open" shadowrootcustomelementregistry> 
    <div>null</div>
  </template>
</div>`);
const el = contentDocument.body.firstElementChild.shadowRoot.firstElementChild;
console.assert(el.customElementRegistry === null)
document.adoptNode(el);
console.assert(el.customElementRegistry === null, 'customElementRegistry mutated when adopted and it was previously null')```

 

[annevk]

@ja-y-son ah, you are right. I overlooked that when writing that test. We should probably just fix the test. Are you interested in doing that?

@sorvell a null registry is always mutated when it comes into contact with a subtree that has a registry.

[ja-y-son]

Yup happy to help fix the tests. Think there are couple tests in adoption.window.js that have the same issue.

[sorvell]

@annevk I think maintaining an explicit null registry state is valuable. I opened #1413 which is more specific so maybe we can discuss it there.