You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any time we create a JS object, and more generally, any time we (indirectly) use a %WellKnownIntrinsicObject% from the TC39 spec, there needs to be a "current realm" available. For objects meant to be associated with the main document's realm, this means avoiding %Intrinsics% from 'in parallel' contexts.
There are a couple ways to fix this second problem. You could create the new realm earlier, before the spec creates any of the JS objects meant for it, or you could move the JS object creation down into 'evaluate a script'. To do the latter, I think you'd want to pass them as WebIDL objects to 'evaluate a script', convert |F| to the appropriate WebIDL callback function type, and use 'invoke' to call it. This might take some changes to WebIDL, which doesn't currently have a type representing an object parsed from a JSON string, and which assumes a non-empty [[HostDefined]] settings object.
The text was updated successfully, but these errors were encountered:
Any time we create a JS object, and more generally, any time we (indirectly) use a %WellKnownIntrinsicObject% from the TC39 spec, there needs to be a "current realm" available. For objects meant to be associated with the main document's realm, this means avoiding %Intrinsics% from 'in parallel' contexts.
Protected Audience also creates new realms in https://wicg.github.io/turtledove/#evaluate-a-script, but it creates some objects intended for those realms from algorithms like https://wicg.github.io/turtledove/#evaluate-a-bidding-script, before their realm exists or is made the running execution context.
There are a couple ways to fix this second problem. You could create the new realm earlier, before the spec creates any of the JS objects meant for it, or you could move the JS object creation down into 'evaluate a script'. To do the latter, I think you'd want to pass them as WebIDL objects to 'evaluate a script', convert |F| to the appropriate WebIDL callback function type, and use 'invoke' to call it. This might take some changes to WebIDL, which doesn't currently have a type representing an object parsed from a JSON string, and which assumes a non-empty [[HostDefined]] settings object.
The text was updated successfully, but these errors were encountered: