Node insertion step 7.7 isn't upgrading disconnected uncustomized elements that browsers do upgrade
As written, https://dom.spec.whatwg.org/#concept-node-insert 7.7.2.2 only fires for a non-custom node that is connected.
However, WPT tests such as https://github.com/web-platform-tests/wpt/blob/master/custom-elements/reactions/Range.html and https://github.com/web-platform-tests/wpt/blob/master/custom-elements/reactions/HTMLTableElement.html create nodes via createContextualFragment and innerHTML and expect upgrade reactions, even when the nodes are disconnected from the document tree.
Browsers agree with the tests, as seen in the relevant rows of https://wpt.fyi/results/custom-elements/reactions?label=experimental&label=master&aligned.
Essentially, the custom check and the connected check should be swapped, and the otherwise-try-to-upgrade part should be associated with the custom check.
cc @whatwg/components
Hmm. This seems pretty bad to me; the intention is not to ever upgrade disconnected elements unless one explicitly uses customElements.upgrade(). How did we get this wrong when writing tests? Is it too late to fix browsers?
/cc @mfreed7 (who I just invited to @whatwg/components).
All these test cases involve parsing, so it's conceivable that browsers are actually doing the right thing on the insertion and the wrong thing is when they're parsing the HTML fragment.
If it's happening during the fragment parsing, rather than during the insertion: https://html.spec.whatwg.org/multipage/parsing.html#parsing-html-fragments tells us to parse into a new document instead of the browsing context one, and https://html.spec.whatwg.org/multipage/custom-elements.html#look-up-a-custom-element-definition tells us not to customize elements if the document has no browsing context, so if a custom element is created in fragment parsing one of those is off.