webidl icon indicating copy to clipboard operation
webidl copied to clipboard

Can a platform object’s associated Realm really change?

Open bathos opened this issue 2 years ago • 4 comments

I’m not sure if the following passage is accurate:

The Realm that a given platform object is associated with can change after it has been created. When the Realm associated with a platform object is changed, its [[Prototype]] internal slot must be immediately updated to be the interface prototype object of the primary interface from the platform object's newly associated Realm.

(Links: bikeshed source; rendered spec).

Supposedly the associated realm of a platform object is, via relevant realm from HTML, the value of its [[Realm]] slot. Their [[Realm]] slots are allocated and set in steps 4 and 5 of internally create a new object implementing the interface.

Nothing in Web IDL appears to reassign those values. There’s an exported definition (dfn-change-global-environment), but it doesn’t seem to be referenced in other specs, either.

It looks like this was written 9 years ago and hasn’t changed apart from markup, formatting and replacement of “global environment” with “Realm”. Is it still accurate? Are there places where this [[Prototype]] swapping really happens that just aren’t linked / picked up by webref?

My best guess is that it might have been intended to explain the behavior of (what we now call) WindowProxy, which I think hadn’t yet been formalized. A WindowProxy isn’t itself a platform object and the hypothetical Window objects that they proxy have static [[Realm]] values, as far as I know, so it could just be text that became outdated when that more complete explanation of “windowness” was specified.

bathos avatar Sep 13 '22 03:09 bathos

Historically, I believe Gecko implemented document.open by creating a new realm and then "reparenting" existing DOM node objects to the new realm. That logic is since long gone, and assuming there isn't anywhere else that could change the realm of an object (I cannot recall any) we should be able to remove it.

TimothyGu avatar Sep 13 '22 06:09 TimothyGu

Document.adoptNode also reparents in Gecko. I don't know of any plans to change that at this point, though we never got cross-browser agreement on it (eg see also the mega-thread at https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567).

petervanderbeken avatar Sep 13 '22 06:09 petervanderbeken

@TimothyGu Oh wow — I (think I) remember reading about that [[Prototype]]-swap-on-adoption behavior a long time ago (in spec text I think? was it specified at one point?). It looks like maybe this impressive/terrifying set of changes (part 5 & 6?) were where the long gone logic you mentioned got gone. Didn’t realize document.open used to be even weirder!

@petervanderbeken That thread is wild lol. “Re-parenting primitives”! Calling web devs “muggles” unironically!? This????? Only one third through but I love the chaos density & the insight into how folks were thinking about this a decade ago so much — thank you for linking this.

bathos avatar Sep 13 '22 11:09 bathos

Yeah, so we should definitely remove this from Web IDL; great catch. Ideally we'd do so while also committing (or checking for the preexistence of) web platform tests, for the document.open and node-adoption cases.

domenic avatar Sep 14 '22 21:09 domenic