Custom element inside <template> uses registry of owner document

[pshaughn]

WPT custom-elements/parser/parser-uses-registry-of-owner-document is testing this; document.write('<template><my-custom-element></my-custom-element></template>') is having my-custom-element interpreted in terms of the custom element registry, which it shouldn't because it's inside a template.

[pshaughn]

What's supposed to be happening here is that, during parse of a template, new elements are added to a document fragment associated with the "template contents owner document", as described in https://html.spec.whatwg.org/multipage/scripting.html#appropriate-template-contents-owner-document. This document isn't supposed to share a custom element registry with the main document being parsed, and so its registry should be empty during this test, meaning we should have an element with a custom element state of "undefined" and an is value of "my-custom-element". The test then inspects this without moving it into the main document, so it should never be upgraded to the custom element constructor.

[pshaughn]

My previous comment was assuming we were hitting the synchronous upgrade during parse; another possibility that needs to be distinguished is that we might be parsing it without upgrading, but then upgrading when we add the template node to the document. If that's the case, then the problem is that we're recursing into the contents of the template's fragment when we iterate over its descendants. Since templates in HTML documents seem to be mostly behaving themselves, I'm leaning towards the parser hypothesis but I haven't made any tests to distinguish the possibilities yet.

[pshaughn]

Both things can go wrong, the parser and the append.

custom-elements/parser/parser-uses-registry-of-owner-document.html fails because the parser is synchronously creating the custom element when it should be in the template state.

custom-elements/reactions/Document.html "succeeds" right now because a disconnected node is never getting upgrades, but after the fix of #24992 it fails because the innerHTML setter is appending the customizable element and a reaction is enqueing from the append.

I don't know if I can fix the parser one but I think I can fix the append one.

[pshaughn]

The parser case is a result of #18277, and it looks like #18536 was a strong but abandoned move towards solving the parser case both in servo and in html5ever.

[pshaughn]

https://w3c.github.io/DOM-Parsing/#the-innerhtml-mixin directs us to https://w3c.github.io/DOM-Parsing/#dfn-fragment-parsing-algorithm and this happens before the step that cares whether we're in a template. The "context element" passed to the fragment parsing algorithm is the template itself.
https://w3c.github.io/DOM-Parsing/#dfn-fragment-parsing-algorithm says create a fragment that has the owner doc of the parent node, and then to append into it, specifically so that the appended nodes will end up in the "correct" node document.
However, if the parent node was a template, this is not the correct owner document!

The obvious thing to try here is just swapping steps 1 and 2 so we're parsing on the fragment instead of on the template; I'll see if that works (a fragment isn't an "element" so doing literally that does not work; trying something similar)

[pshaughn]

I might be wrong about this, but Servo can pass the test if it checks for templateness a little more aggressively; filed w3c/DOM-Parsing#61

[pshaughn]

It's possible the part of #25730 that relates to templates is worth keeping even if the rest of it turns out to be following a bad WPT test.