[Scoped Registries] Can disconnected elements can retain their shadowroot via dangling treeroot pointer?

[keithamus]

In w3c/tpac2024-breakouts#26 we discussed the idea of how we could store the shadowroot of an element created with shadowroot.createElement. Storing the originating shadowroot of calls to this would make this APIs much more ergonomic, as calls to for e.g. innerHTML on that node could retain the scoped registry in order to correctly assign definitions to custom elements during that call. Without this these APIs take an ergonomic hit.

It was raised after the meeting (and therefore not in the minutes) that one way to do this without introducing overhead would be to utilise the dangling pointer for the "TreeRoot", which is a nullptr for disconnected nodes. In Chromium this pointer is to Node, nsINode in Gecko and EventTarget in WebKit. Each of these classes has a set of bitflags with what looks like 1 flag remaining (Chromium's NodeFlags, and WebKit's EventTargetFlag explicitly mention 1-bit free, and while Gecko's BooleanFlag uses 32 bits, the last bit is a guard value which could potentially be repurposed).

So - just to check in with implementers (and specifically @emilio, @mfreed7, @rniwa who were in the meeting and may recall the discussion, also /cc @smaug---- for more confirmation on the Gecko side) - could we always populate the TreeScope with a Node subtype or Node instance which has a new bit set to say "this is a dummy proxy Node that points to a parent but shouldn't be given to script, and is just for keeping the shadowroot reference alive so that createElement & co work seamlessly" (the variable name could use some bikeshedding).

[mfreed7]

So - just to check in with implementers (and specifically @emilio, @mfreed7, @rniwa who were in the meeting and may recall the discussion, also /cc @smaug---- for more confirmation on the Gecko side) - could we always populate the TreeScope with a Node subtype or Node instance which has a new bit set to say "this is a dummy proxy Node that points to a parent but shouldn't be given to script, and is just for keeping the shadowroot reference alive so that createElement & co work seamlessly" (the variable name could use some bikeshedding).

I'm supportive of an approach like this to allow us to keep track of the link to follow to find the correct (scoped) registry. One nit might be that I was thinking you'd put a bit on Element that means "my TreeScope reference isn't real - I'm disconnected. But the TreeScope reference does point to a TreeScope that has a registry that you can use for element creation". That's maybe what you meant by that paragraph, but I just wanted to make sure. But that's really in the details - I'm supportive.

[keithamus]

Oh yeah 🤦 that makes much more sense!

[rniwa]

Could someone clarify the exact situation in which this will be useful again?

[justinfagnani]

Could someone clarify the exact situation in which this will be useful again?

When you create an element via a scoped registry, but it's not attached to the document, ie:

const el = shadowRootWithRegistry.createElement('div');
el.innerHTML = `<x-foo></x-foo>`;
shadowRootWithRegistry.append(el);

We don't want <x-foo> upgrading in the gloabal registry in this case.

[rniwa]

But the element isn't gonna upgrade until it's connected anyway, and at the time of connection, the element belongs to the shadow root with the scoped custom element registry so the normal lookup would work.

[justinfagnani]

If <x-foo> defined in the global registry it will upgrade immediately, right?

[rniwa]

No. Customer elements only upgrade when they're connected.