Scoped custom element registry issues

[AtkinsSJ]

What is the issue with the DOM Standard?

A collection of issues I've bumped into while implementing "scoped custom element registries" in Ladybird, in one place to hopefully make them easier to deal with. There might be more but I haven't yet found a way to work around these:

---

All of the "Operator 'new' should instantiate a customized built-in element" subtests of https://wpt.live/custom-elements/builtin-coverage.html fail. I think the issue is we're not putting the constructor in the agent's "active custom element constructor map" when new is used, but I'm not sure.

---

https://dom.spec.whatwg.org/#concept-create-element step 5.1.3.1 constructs the element, but its registry isn't set until 5.1.3.11. Ladybird might be doing something else wrong, but currently this means the custom element's constructor is called with it having no registry set. That breaks the tests in https://wpt.live/custom-elements/form-associated/ElementInternals-setFormValue-nullish-value.html which call attachInternals() inside the custom element's constructor.

---

The final test of https://wpt.live/custom-elements/registries/upgrade.html fails. It has this note in the source:

  // Template contents owner documents don't have a browsing context, so
  // https://html.spec.whatwg.org/multipage/custom-elements.html#look-up-a-custom-element-definition does not find any
  // custom element definition.

However, "look up a custom element definition" no longer checks for a browsing context.

[AtkinsSJ]

cc: @annevk

[annevk]

Is the problem with 2 that https://html.spec.whatwg.org/multipage/dom.html#htmlconstructor doesn't set the registry?

The upgrade() case seems like it should still not result in upgrades because the element won't have an associated registry.

[AtkinsSJ]

Is the problem with 2 that html.spec.whatwg.org/multipage/dom.html#htmlconstructor doesn't set the registry?

Aha! Setting its registry in step 9 of that does fix 1 and 2. Good call.

[AtkinsSJ]

I've just looked into 3 again. If I remove my ad-hoc "if the navigable has no active document, return" from between steps 4 and 5 of "destroy a child navigable", the crash is now happening in a different test: custom-elements/registries/scoped-registry-define-upgrade-order.html. It's possible that that's just a bug in my/Ladybird's code, I do see a few other regressions still. But it should be a lot easier to track those down without the big failures caused by not setting the registry in HTMLConstructor. I'll take a look next week.