-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JavaScript ShadowRealm proposal integration #9893
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes to the module loading algorithms look ok.
For the record, we (people working on modules in TC39) have some ideas for splitting the stateless and stateful parts of Module Records in ECMA-262. If/once that will happen, it would be great to share a module map for the stateless parts across principal realms and shadow realms, so that basically in this case:
import "/foo";
new ShadowRealm().importValue("/foo", "bar");
we only call into fetch once (to get the stateless part) and then we create the stateful part twice in both realms.
I think this could benefit from review at this point |
Delete the Exposed attribute from AbortSignal.timeout, letting it inherit [Exposed=*] from AbortSignal. Cf. whatwg/html#9893 where other timers are being exposed in ShadowRealm global contexts.
ShadowRealms reached 2.7 in TC39. Acceptance of this PR by WHATWG editors is a blocking requirement for Stage 3, though it probably shouldn't be landed until the Web API set is finalized. |
4fd9960
to
9d8d9ec
Compare
This aligns with the lastest version of the PR implementing the javascript shadow realm proposal: whatwg/html#9893 This commit simply performs the rename before implementing the behaviour change.
…n in 'run a classic/module script'
This patch gives the TC39 JavaScript ShadowRealm proposal semantics in HTML. ShadowRealms are given an environment settings object; in general, ShadowRealms inherit their settings from the outer environment. When modules are used in ShadowRealms, module specifiers are interpreted with respect to the base URL of the surrounding environment, but when a module is imported within a ShadowRealm, it is a separate copy from what may be loaded in the surrounding environment or other ShadowRealms. This patch implements the plan described earlier at <tc39/proposal-shadowrealm#225 (comment)>. The ShadowRealm proposal is currently at Stage 2. Once this PR has been approved, it should be able to advance to Stage 3.
This avoids issues with ShadowRealms importing modules that the principal realm hasn't cached (yet).
As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness.
As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness.
As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness.
To replace #5339.
ShadowRealm
constructor denoland/deno#16211(See WHATWG Working Mode: Changes for more details.)
/browsing-the-web.html ( diff )
/dom.html ( diff )
/embedded-content.html ( diff )
/form-elements.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/media.html ( diff )
/nav-history-apis.html ( diff )
/references.html ( diff )
/scripting.html ( diff )
/structured-data.html ( diff )
/timers-and-user-prompts.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )