-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider defining a Realm (global) for all objects, not just Functions #1333
Comments
Note that IDL already requires this: https://heycam.github.io/webidl/#dfn-associated-realm. https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke also relies on this for initializing the global variable. |
Realms distinguishes two kinds of realms, "root realms" and "compartments" (the documentation needs to be updated. This distinction is clearer in the shim and in recent talks.) A root realms is associated with a fresh set of primordials. Each realms, both root realm and compartment, has its own global. Each compartment has its own evaluators that evaluate in the scope of its own global. There can be many compartments per root realm. For purposes of this thread, the relevant concept is root realm. WeakRefs requires that every obj is associated with a root realm. A weakref created in one root realm initialized to point at an object in another root realm can only point strongly, not weakly, in order to avoid creating an egregious new side channel. attn @jfparadis @dtribble @warner @FUDCo @marjakh @bmeck @tschneidereit |
Great. :) |
@bzbarsky this seems answered; is it OK to close? |
I don't think so; this would be closed once every object has an associated Realm, and thus the spec matches implementations. The urgency for doing so on the ES side seems to be low (but will increase as WeakRef progresses), but it'd still be good to do, and would immensely benefit web reality integration, allowing us to remove the monkeypatch in https://heycam.github.io/webidl/#dfn-associated-realm |
What is the answer? Is a Realm defined for all objects, or is it not going to happen? In the former case, where does the definition live? |
Associating each object with a root realm becomes a necessary operational distinction once we have WeakRefs. Until then, adding the spec language has no observable effect. If someone is willing to do the work to write the spec language explaining what root realm each object is associated with, I would like to see this move forward sooner rather than later. That way, implementors can start to align their implementations with this before it becomes observable. |
@erights within a browser it's definitely observable. Which means it might end up being a compatibility hazard if not done the way browsers do it today. |
Do the realms here coincide across browsers completely? The specification seems kind of |
It's vague on where the Realm comes from, though not deliberately so (it's a lot of work to define that). And it's definitely all objects, not just platform objects. See also OP. |
I see how it's observable; what I don't know is whether all browsers actually use the relevant realm of the object, or some may use other realms for such cases. |
@gsathya (who's working on the WeakRef spec too) |
It seems like the next steps here are for someone to do the research for what web reality is here, and then write up specification text that codifies it? |
During the last TC39 meeting, @gsathya and @ajklein said that V8 wouldn't implement this, because it'd either be too slow, or require adding a new slot to every object. I'm not 100% sure that this precludes finding the correct Realm for every use case, though: this discussion was strictly about WeakRefs, for which it would be too costly. |
A specific motivating example is the DOM event listener API. This takes an object which can be a function or can be an object with a
handleEvent
property. In the latter case, when the event fires, the value of the property is gotten (via[[Get]]
) and then called as a function.This raises at least two problems in terms of DOM integration:
If the
[[Get]]
throws, the exception needs to be reported to the error handler on a global. Which global?If the property getter is a bound version of the
postMessage
function, which wants to examine the "global of its caller", how should that be defined in this case? That is, where does the event processing algorithm get a global before it calls[[Get]]
? There are attempts to remove this "global of its caller" concept in Minimize the usage of the incumbent concept whatwg/html#1430 but at the moment it's not really making progress.There are similar issues with Promise integration into the DOM, last I checked, but I don't recall the details. Maybe @domenic might.
Anyway, in the past there has been some resistance to defining a Realm for all objects, but maybe it's worth looking into the issue again.
// cc @littledan
The text was updated successfully, but these errors were encountered: