Skip to content

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

Closed
@keithamus

Description

@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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions