Skip to content
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

Open
bzbarsky opened this issue Oct 24, 2018 · 14 comments
Open
Labels
layering affects the public spec interface and may require updates to integrating specs needs specification text The proposal should specify ecmarkup changes that can easily merge into tc39/ecma262/spec.html. web reality

Comments

@bzbarsky
Copy link

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

@annevk
Copy link
Member

annevk commented Oct 24, 2018

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
Copy link

erights commented Oct 24, 2018

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
Copy link
Author

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

Great. :)

@ljharb
Copy link
Member

ljharb commented Jan 29, 2019

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

@domenic
Copy link
Member

domenic commented Jan 29, 2019

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
Copy link
Author

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?

@ljharb ljharb added web reality needs specification text The proposal should specify ecmarkup changes that can easily merge into tc39/ecma262/spec.html. and removed question labels Jan 29, 2019
@erights
Copy link

erights commented Jan 29, 2019

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
Copy link
Member

annevk commented Jan 30, 2019

@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
Copy link
Member

littledan commented Jan 30, 2019

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
Copy link
Member

annevk commented Jan 30, 2019

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
Copy link
Member

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
Copy link
Contributor

marjakh commented Jan 30, 2019

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

@ljharb
Copy link
Member

ljharb commented Apr 28, 2019

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
Copy link
Member

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.

@annevk annevk added the layering affects the public spec interface and may require updates to integrating specs label May 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
layering affects the public spec interface and may require updates to integrating specs needs specification text The proposal should specify ecmarkup changes that can easily merge into tc39/ecma262/spec.html. web reality
Projects
None yet
Development

No branches or pull requests

8 participants