[whatwg/dom] Scoped custom element registry issues (Issue #1379)

AtkinsSJ created an issue (whatwg/dom#1379)

### 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:
```js
  // 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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1379
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1379@github.com>