tc39 / ecma262

Status, process, and documents for ECMA-262
https://tc39.es/ecma262/
Other
15.03k stars 1.28k forks source link

Consider defining a Realm (global) for all objects, not just Functions #1333

Open bzbarsky opened 5 years ago

bzbarsky commented 5 years ago

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:

1) If the [[Get]] throws, the exception needs to be reported to the error handler on a global. Which global?

2) 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 https://github.com/whatwg/html/issues/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

annevk commented 5 years ago

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.

erights commented 5 years ago

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

bzbarsky commented 5 years ago

WeakRefs requires that every obj is associated with a root realm.

Great. :)

ljharb commented 5 years ago

@bzbarsky this seems answered; is it OK to close?

domenic commented 5 years ago

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

bzbarsky commented 5 years ago

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?

erights commented 5 years ago

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.

annevk commented 5 years ago

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

littledan commented 5 years ago

Do the realms here coincide across browsers completely? The specification seems kind of deliberately vague. I am not sure if we should have an associated realm per object, or per platform object. Note that ECMAScript typically uses what web specs call "the current realm" rather than "the relevant realm", which reduces the need for an associated realm attached to an object. Cc @ms2ger @verwaest

annevk commented 5 years ago

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.

littledan commented 5 years ago

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.

marjakh commented 5 years ago

@gsathya (who's working on the WeakRef spec too)

ljharb commented 5 years ago

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?

tschneidereit commented 5 years ago

WeakRefs requires that every obj is associated with a root realm.

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.