[Stage 3] behavior of global object

[mhofman]

Originally this proposal created a regular object for the global and provided a host hook to add configurable properties and change the prototype according to the APIs the host needed to expose.

#392 attempted to change that, to which I objected. The spirit of the changes in that PR were subsequently absorbed in other PRs and #392 was closed.

To satisfy virtualization use cases, the global object in a ShadowRealm must remain effectively fully configurable and with a behavior observably similar to a regular object. There is no way to specify such constraints on a host besides having the 262 spec create the global object. That means in InitializeHostDefinedRealm, step 12.a must be prevented for the ShadowRealm global, and the Else path in 12.b must be used.

If the host requires use of an exotic object to serve as realm's global object

To clarify, while the host must not be allowed to observably use an exotic object, that requirement does not prevent an implementation to actually use an exotic object as global object, as long as the exotic behavior is observably indistinguishable from a regular object behavior.

[caridy]

I discussed with igalia in details... here is where we are:

• there are two host hooks: InitializeHostDefinedRealm and HostInitializeShadowRealm
  • InitializeHostDefinedRealm is currently only triggered from syntax (eval) and others forms of executing something in the language (into a new realm). The result of that is that it creates a new realm, with a new global obj (more on that soon), and set up the context for the immediate execution of code in that context right away.
    • In here, there is another important aspect, https://tc39.es/ecma262/#sec-initializehostdefinedrealm, the creation of the global obj, which follows the definition of exotic objects, in which case, the host owns that definition, otherwise it is an ordinary object. In the web, global objects are demarked as exotics.
  • HostInitializeShadowRealm is designed to allow host to add ShadowRealm's specific APIs into the global object (basically the things that should be there initially).

Now the problem:

When new ShadowRealm() is invoked, it calls InitializeHostDefinedRealm without providing any information, which means the host might not know what kind of global obj to create. That's ok if we were to rely on HostInitializeShadowRealm to do that part, but for non-shadowRealm, you don't have an equivalent mechanism, so how will the host do its job?

The other issue is that there is no provision about what InitializeHostDefinedRealm can or cannot do, like we do for HostInitializeShadowRealm , which prevents them from defining non-configurable global properties.

The other question is whether or not the global object should be ordinary or exotic. We pushed for it being an ordinary object, since there is nothing special about it, and so far we haven't get any push back from implementers. As far as I can tell, they just need to associate that object to the other internal mechanism (settings object, etc.). I believe we can do something similar to what we do in HostInitializeShadowRealm, to make sure no special behavior is ever added to that global object.

[ptomato]

I think we're all in agreement about this goal — it's just a question of how to specify it conveniently and without creating a lot of duplication.

Ms2ger and I talked today and we think it could be sufficient to add an assertion in the ShadowRealm constructor along the lines of:

Assert: O.[[ShadowRealm]].[[GlobalObject]] is an ordinary object.

or possibly, if it turns out to be necessary from the host's side:

Assert: O.[[ShadowRealm]].[[GlobalObject]] is an ordinary object, or an exotic object behaviourally equivalent to an ordinary object.

This seems like it'd place the necessary restrictions on what hosts can do inside InitializeHostDefinedRealm.

Also, just want to reiterate that nobody is trying to sneak any exotic behaviour in here! Unfortunately the ECMA-262 refactoring in tc39/ecma262#3139 seems to have opened this possibility, so now we need to add language like what I suggested above, to prevent it. But it's never been a goal of either #392 or #409 to enable exotic behaviour of ShadowRealm global objects.

[Jack-Works]

just want to reiterate that nobody is trying to sneak any exotic behaviour in here

Is WindowProxy exotic?

[Ms2ger]

just want to reiterate that nobody is trying to sneak any exotic behaviour in here

Is WindowProxy exotic?

We're not putting WindowProxys in ShadowRealms, so I'm not sure why you ask

[mhofman]

Solved by #413