Repository navigation
When creating a global object the realm is not yet initialized #1547
Description
What is the issue with the Web IDL Standard?
This hits step 1 of https://webidl.spec.whatwg.org/#internally-create-a-new-object-implementing-the-interface
But also 1.1 of https://webidl.spec.whatwg.org/#define-the-operations and 2.2.1 of https://webidl.spec.whatwg.org/#dfn-create-operation-function.
Some of this could maybe be helped if we set realm.[[GlobalObject]] ourselves, but there's a further issue in that https://webidl.spec.whatwg.org/#dfn-exposed needs access to the settings object which isn't created until after the realm in HTML. I think that's information we need to pass in explicitly somehow instead, at least when allocating the global object.
Activity
jmdyck commentedon Nov 28, 2025
To be clear, the realm is not completely initialized. It does have realm.[[Intrinsics]], which is useful.
Set it to what? A really simple object, or a special value like
null?annevk commentedon Nov 28, 2025
I was thinking after step 6 of https://webidl.spec.whatwg.org/#internally-create-a-new-object-implementing-the-interface (in the case where we are creating a global object). That would at least do the right thing for 2.2.1 of https://webidl.spec.whatwg.org/#dfn-create-operation-function (and a similar step for getters and setters).
I think that leaves solving for "exposed". Perhaps that's a check we can bypass when we create the global.
jmdyck commentedon Nov 28, 2025
Ah, you mean set realm.[[GlobalObject]] to its proper value, just earlier in the whole process than happens currently.
shannonbooth commentedon Jun 14, 2026
I've looked into this somewhat, and I think we can fix this using a slightly modified version of tc39/ecma262#3728 in combination with some somewhat larger changes in the HTML spec where InitializeHostDefinedRealm / "create a realm" is used.
Instead of creating a global object and then the ESO, perhaps we can create the ESO first, then the global object. This will allow the Exposed checks on creation of the global object to use the ESO.
To make this work, we will need to:
I haven't gotten all of the way through in terms of validating the above, but I've gotten far enough that I'm fairly confident that approach can work.
The only other way I can think of to fix this is to defer the full initialisation of globals until after the ESO is created, but this is quite a bit uglier (though this is the approach taken in ladybird implementation currently as a workaround).
annevk commentedon Jun 16, 2026
#1608 and whatwg/html#12580 provide a draft for this now. I think it works, but happy to refactor further.