Custom element registry for elements created inside <template for> #13076

What is the issue with the HTML Standard?

Create an element for a token looks up the registry from the intended parent:

Let registry be the result of looking up a custom element registry given intendedParent.

For content inside a <template for>, insert a foreign element passes the target parent of the appropriate place for inserting a node. For a template with a non-null insertion target, that's the insertion target:

If targetParent's insertion end marker is not null and its parent is patchInsertionTarget, then return (patchInsertionTarget, targetParent's insertion end marker).

So patched content gets the same registry as content parsed in place at the marker. Chrome Canary 157 uses the parser's registry instead:

<script>customElements.define("x-foo", class extends HTMLElement {});</script>
<div id=host><template shadowrootmode=open shadowrootcustomelementregistry><x-foo id=direct></x-foo><?marker name="m"><template for=m><x-foo id=patched></x-foo></template></template></div>

The shadow root's custom element registry is null. Per spec, both x-foo elements have a null registry and stay undefined. In Chrome Canary 157, #direct does, but #patched has the global registry and is upgraded.

Gecko's in-progress implementation (bug 2053472) also uses the parser's registry.

The spec's behavior seems more consistent, since patching shouldn't change how content parsed at the marker is created. If so, this needs a WPT.

cc @foolip @noamr