Update element adoption logic for scoped registry

[ja-y-son]

Fixing #1429 to make sure element is getting the correct scoped custom element registry upon adoption.

• At least two implementers are interested (and none opposed):
  • Webkit
  • Chromium
• Tests are written and can be reviewed and commented upon at:
  • Add test cases for null registry element upon adoption web-platform-tests/wpt#56423
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/399124619
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1874414
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=302970
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

This looks good to me. We'll need tests next.

For the tests I'd like us to exercise some of the more complicated scenarios with some nodes having been assigned registries and others not, etc.

[ja-y-son]

Just added some tests but I haven't fully verified them yet. Feel free to take a look.

[ja-y-son]

@annevk Want to verify that this is the expected behavior from this change on effective gloabl registry. Consider this test case from adoption.window.js

test(t => {
  const contentDocument = document.body.appendChild(document.createElement('iframe')).contentDocument;
  t.add_cleanup(() => contentDocument.defaultView.frameElement.remove());
  const element = document.createElement('div');
  assert_equals(element.customElementRegistry, customElements);

  const scoped = new CustomElementRegistry();
  const scopedElement = contentDocument.createElement('div', { customElementRegistry: scoped });
  contentDocument.body.appendChild(scopedElement);
  assert_equals(scopedElement.customElementRegistry, scoped);
  scopedElement.appendChild(element);
  assert_equals(element.customElementRegistry, contentDocument.customElementRegistry);
}, "Adoption with global registry into a scoped registry");

Given that now we look at the parent's registry's effective global registry, the last assert of the test should probably be

assert_equals(element.customElementRegistry, null);

given that the parent is using a scoped registry.
Is this expected? Or we want it to keep getting global registry for this element? It feels a bit odd that it originally has a global registry but after adoption it goes to null registry. Perhaps we should make sure that non-null registry element shouldn't get null registry after adoption (unless there are no global registry available)?

[annevk]

Yeah, I suppose distinguishing those cases would be better. I doubt anyone is going to run into this in practice, but we might as well make it nice.

[ja-y-son]

I think I made it unnecessarily complicated in the previous iteration. Given that our main goal is that global registry element shouldn't become null registry during adoption, I think we can simply include this category (global registry) to use document's registry's effective global registry, so it wouldn't be getting null from parent. Does this make sense? Or perhaps I'm missing something here.

[annevk]

Yeah I think this works. I'll re-review on Monday to be sure. If @sorvell, @rniwa, and maybe @keithamus could have a look as well that'd be great.

(Checking inclusiveDescendant's custom element registry again bothers me a little bit, but I don't see a good way out of that. I also want to double check the "DocumentFragment but not ShadowRoot" language.)

[ja-y-son]

@annevk Went through this PR again and I think it still works. Do we want to merge this PR first while wrapping up web-platform-tests/wpt#56423

[annevk]

Also, now that "keep custom element registry null" is part of this PR, it depends on whatwg/html#12000 so we should mention that in the commit message and get that PR finished as well.

[ja-y-son]

I updated the commit message so it mentions the new concept that will be defined in whatwg/html#12000. I'll prioritize getting this adoption logic PR landed and will for sure get the attribute PR finished next. Let me know if you prefer me to take "keep custom elemetn registry null" idea out of this PR for now; I can also land this PR without the concept and put it together with attribute PR.

[annevk]

Let's keep it out of this PR then.

[ja-y-son]

@annevk Thanks for the review and the nit! I don't seem to have the permission to merge the PR. Mind landing this PR for me?

[annevk]

Ryosuke said he'd make time for the tests this week and I'd like to wait for that as we land tests and specification changes around the same time.