caridy
commented
2 weeks ago I discussed with igalia in details... here is where we are:
- there are two host hooks:
InitializeHostDefinedRealmandHostInitializeShadowRealm- 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).
- 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.
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
Jack-Works
Ms2ger
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.
https://github.com/tc39/proposal-shadowrealm/pull/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.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.