Let the host create the global object #392
Conversation
| The ShadowRealm constructor (<emu-xref href="#sec-shadowrealm"></emu-xref>) | ||
| creates a new global object as an ordinary object. This | ||
| means all properties from the global object are deletable. | ||
| The host is expected to create global object whose properties are all deletable. |
There was a problem hiding this comment.
| The host is expected to create global object whose properties are all deletable. | |
| The host is expected to create a global object whose properties are all deletable. |
Although I think this note is redundant, the paragraph above already states:
The host may use this hook to add properties to the ShadowRealm's global object. Those properties must be configurable.
...and configurable means deletable.
|
This change looks like a regression. It seems that the host gains the ability to create a global object with exotic behavior. In particular the main requirement is that all properties must be effectively deletable. I also believe the intent was for the prototype of the global object to be effectively mutable, and that the global object could be successfully frozen. The reason I mention "effectively" is that an exotic object can claim that properties are configurable, yet refuse to actually mutate or delete them. |
|
I'm happy to add restrictions on the host, but would prefer if someone with more background suggested prose for it. |
|
#394 raises an interesting point about discovery of the host added properties. If the host creates the object, it should implement all added properties as own properties. I think basically the constraint should be that all behavior implemented by the host created global object be observably regular / non-exotic. In this case the object invariants are not sufficient as they provide too much leeway. At which point I'm still curious why we need this change since a host created object with regular object behavior, and a spec created regular object are observably indistinguishable, and can be considered an internal implementation concern. |
|
@mhofman, could @ljharb's "Get Intrinsic" Proposal help reconcile these concerns? We could use it to enumerate the global object's properties in a ShadowRealm and delete all or some of them (because they're required to be configurable, though that requirement would have to be strengthened so that the delibility isn't faked), e.g. just those added by the host. And hosts with |
|
I oppose to host creating the global object. Without userland ShadowRealm API to do the same thing, an exotic global object is unacceptable. Can you give the reason why the host should take over the creation? |
I don't see how that proposal would help. The concern is not with the ability to enumerate globals, but with requiring that the global object has non-exotic behavior.
Why is the host creating the global object required for this? The prototype of a fresh regular object is mutable. Nothing in the original steps says the global object has to inherit from |
|
The host can set the global object's prototype to EventTarget.prototype in |
|
@mhofman, you wrote:
If instead it creates a regular object as global and operates on it in
What I mean by the (actually understated; worse things can happen) latter is, assuming that in the absence of Get Intrinsic (which I therefore mentioned) you'd traverse the prototype chain with |
|
Or maybe it's fine to change the prototype of the global object first (it's ordinary, so possible), thereby loosing its But even then, I believe the requirements of |
That's fine, as long as the global object remains extensible, the prototype object can be substituted, which is sufficient.
The configurability requirement does not apply to the prototype chain, only to the global object.
Nope, you'd likely replace the prototype of the global object with a wrapper or other object that behaves as expected.
Right, but the user doesn't have to lose the
I agree,
Yes, I wanted to have some text somewhere that prevented the host from making properties appear or otherwise change properties on the global object after
I honestly don't care about what the host does outside the shadow realm after its creation, as long as it respects the callable boundary invariants (which are now spelled out precisely) and the above requirements to not further change the global object after initialization. |
that's ok, because you can do it in the user land with Proxy. but you cannot make the global object itself becomes a Proxy.
I agree. It is (if not, it must is) a formal requirement to implementations that all properties are configurable, even if they installed it in |
Ms2ger
force-pushed
the
host-creates-global
branch
from
227dc77 to
6dd670c
Compare
| 1. Perform SetRealmGlobalObject(_realmRec_, *undefined*, *undefined*). | ||
| 1. Perform ? SetDefaultGlobalBindings(_O_.[[ShadowRealm]]). | ||
| 1. Perform ? HostInitializeShadowRealm(_O_.[[ShadowRealm]]). | ||
| 1. Let _realmRec_ be the Realm of _context_. |
There was a problem hiding this comment.
@Ms2ger I'm confused about this line, and the title of this PR. Who is creating the realm now?
There was a problem hiding this comment.
CreateRealm was folded into InitializeHostDefinedRealm in tc39/ecma262#3139, it creates a realm, customizable global object, and execution context which is pushed to the stack. This may be changed again slightly in tc39/ecma262#3274.
There was a problem hiding this comment.
I'm also a little confused, and still don't understand the purpose of this PR. For ShadowRealm we need a global object with observably non-exotic behavior. Why can't we just let the 262 spec pretend it created a regular object to use as global, and have implementations actually implement it differently if they want to have their global object with exotic behavior that is non observable?
There was a problem hiding this comment.
In tc39/ecma262#3139 I see the following:
If the host requires use of an exotic object to serve as realm's global object, then
Can we in any way constraint here that the host is not allowed to use an exotic object for the global object of ShadowRealm? And thus pretend that observably we took the path of the Else and created a regular object for the global?
|
I'll come back to this after #409 |
As described in the comments, this was a bug in the shadow realm spec. For now, just apply a fixup to the execution context so that it works as intended. Once tc39/proposal-shadowrealm#392 is updated to match these changes to the spec we should be able to implement this in a better way :^)
As described in the comments, this was a bug in the shadow realm spec. For now, just apply a fixup to the execution context so that it works as intended. Once tc39/proposal-shadowrealm#392 is updated to match these changes to the spec we should be able to implement this in a better way :^)
As described in the comments, this was a bug in the shadow realm spec. For now, just apply a fixup to the execution context so that it works as intended. Once tc39/proposal-shadowrealm#392 is updated to match these changes to the spec we should be able to implement this in a better way :^)
As described in the comments, this was a bug in the shadow realm spec. For now, just apply a fixup to the execution context so that it works as intended. Once tc39/proposal-shadowrealm#392 is updated to match these changes to the spec we should be able to implement this in a better way :^)
As described in the comments, this was a bug in the shadow realm spec. For now, just apply a fixup to the execution context so that it works as intended. Once tc39/proposal-shadowrealm#392 is updated to match these changes to the spec we should be able to implement this in a better way :^)
|
I'm looking into this; at this point it seems like this PR might not be necessary. |
That's because other PRs completely absorbed the original change from this PR. However the concerns I raise are valid more than ever. I will open an issue that must be addressed before proceeding to stage 3. |
|
Filed #411 |
Ref whatwg/html#7591