Using the is= property in innerHTML and in Range.createContextualFragment isn't using the custom element class

[pshaughn]

This is test case "innerHTML should instantiate a customized build-in element" in WPT custom-elements/builtin-coverage.html.

[pshaughn]

and case "createContextualFragment on Range must construct a custom element" in WPT custom-elements/reactions/Range.html

[pshaughn]

The builtin-coverage.html case has been fixed at some point; the Range.html case continues to exist and I'm taking a look at it now.

[pshaughn]

This seems likely to be be a parser problem: createContextualFragment ends up in parse_fragment, where it calls ServoParser::parse_html_fragment. It looks like it's parsing the fragment in the right document context, so the parser should be hitting the custom element registry, but I admit the parser is not a part of Servo I understand very well.

[pshaughn]

Using the wrong registry when parsing a fragment also happens in #25007 and there might be some connection.

[pshaughn]

It looks like we're actually not supposed to have a registry available while parsing the fragment, since https://html.spec.whatwg.org/#html-fragment-parsing-algorithm says to make a new document for the parser and https://html.spec.whatwg.org/multipage/custom-elements.html#look-up-a-custom-element-definition says not to use the registry if there's no browsing context.

However, we create a DocumentFragment using the context document, and we append children to it, and by the time we are appending the children they need to already be custom or they won't be firing the connectedCallbacks they test wants. We're still inside the InnerHTML setter call at this time, so a queued custom element reaction wouldn't have fired; we have to have had a synchronized one by now, despite having parsed into a document with no browsing context.

There might be an actual hole in the specifications here, but it's honestly more likely that I've overlooked some phrasing detail in the spec and I'll try to work it out again in the morning.

[pshaughn]

I was misreading which tests were and weren't expecting a connectedCallback in particular among the callbacks. We do have a problem, but I think my previous comment had the timing of it wrong.

It looks like Servo's problem may be that inserting a customizable node into a document tree correctly causes an upgrade, but inserting a customizable node into a detached tree does not cause an upgrade even if the tree is made of elements created on a document with a registry. I'm going to look deeper under that hypothesis.

[pshaughn]

I now believe this is a mistake in nested step ordering of the DOM spec; whatwg/dom#833