JavaScript ShadowRealm proposal integration #9893

Ms2ger · 2023-10-30T13:57:37Z

To replace #5339.

At least two implementers are interested (and none opposed):
- ShadowRealm API mozilla/standards-positions#997
- …
[·] Tests are written and can be reviewed and commented upon at:
- In progress across multiple pull requests; see https://github.com/web-platform-tests/wpt/pulls?q=is%3Apr+is%3Aopen+shadowrealm
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/issues/41480387
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1797187
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=283289
- Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): [WIP] Implement the ShadowRealm constructor denoland/deno#16211
- Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
MDN issue is filed: Document ShadowRealm mdn/content#36842
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

TODO:

Prepare PRs for dependent specs to adjust to terminology changes

/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 )

nicolo-ribaudo

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.

source

Ms2ger · 2024-02-02T15:10:55Z

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.

littledan · 2024-02-07T22:32:19Z

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.

@domenic @annevk @zcorpan Any thoughts/concerns?

source

Ms2ger · 2024-10-08T15:54:55Z

@domenic or @annevk - it seems to me that the we're making progress on the questions about exposure; is there anything else I can do to help move this PR forward?

source

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.

source

As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness.

Ms2ger · 2024-11-19T14:57:21Z

Let me reproduce @domenic's #5339 (comment) comment here:

I think we have two paths that would be acceptable from my perspective:

Update ECMAScript so that "current Realm" is always a non-shadow Realm.

Continue defining "current global object" / "current settings object" as 1:1:1 with "current Realm".

Very few specs need updating besides ECMAScript; maybe some stuff in core parts of HTML or Web IDL.

Do not update "current Realm".

Introduce "current principal Realm" in either ECMAScript or HTML.

Define "current principal global object" / "current principal settings object" in HTML as 1:1:1 with "current principal Realm".

Maybe remove the definitions of "current global object" and "current settings object", or at least don't export them.

Update all web specs that reference "current Realm" / "current global object" / "current settings object". The latter two seem to be indexed: current global, current settings but for some reason "current Realm" isn't appearing there; not sure why. You can try asking dontcallmedom for help on that (purposefully not pinging him yet though).

I prefer (1) because I think (2) is pretty disruptive to the spec ecosystem, but I can understand how (2) might be more pure from the perspective of the ECMAScript editors. The next step is probably getting their preference.

I think we are going with 2 here, but that means we need PRs for all of https://dontcallmedom.github.io/webdex/c.html#current%20global%20object%40%40html%25%25dfn and similar terms. We would not be able to land this without all of that work being done.

I'm ~~happy~~ willing to take that on, but I'd like to postpone that until this PR is otherwise ready to land. We can't land the PRs to dependent specs anyway (or their links would break), and the changes are highly mechanical, so I don't think there's much of a need to look at them while we do the review here.

source

nicolo-ribaudo · 2024-11-20T11:36:03Z

Is there any reason to ever use the current principal realm, other than to grab the current principal global object and current principal settings object? If not, we probably should not <dfn> it at all.

EDIT: I'm pasting here a message I sent to Ms2ger, since it might help clarify.

The reasons you might want to get to the realm are 4:

to actually use the realm to create objects/functions (in which case, you want the current realm)

to get to the settings object (except for module loading you always want the principal) — and we have the utility defined for this

to get to the global object:

to read properties from it (in which case you want the current)

to check in which kind of global we are (and it seems like you might sometimes want the principal and sometimes want the current)

So we should easily expose what is more likely to be the correct choice, and make it a bit harder to get the one you likely don't want so that you have to explicitly think about it

nicolo-ribaudo · 2024-11-20T13:02:27Z

Looking through all the usages of the current principal global object, it seems like it's also not meaningfully different from the global object associated to the current realm (i.e. the old current global object). Out of 8 usages:

5 are in DOM constructors like new Image. These constructors are not exposed in ShadowRealms, and their current realm and their current principal realm are always the same.
2 are in internal object operations of the WindowProxy, which is obviously not exposed in ShadowRealm
1 is in the pause steps (Ctrl+F for "require the user agent to pause while running" in 8.1.7.3). The current principal global object here is passed to https://w3c.github.io/hr-time/#dfn-current-high-resolution-time. That spec only uses the global object to get its relevant settings object: we could just update that spec to receive the current principal settings object directly.

Looking at the other specs that reference the curent global object, none of them are about APIs exposed in ShadowRealms.

The only places where we actually need the current principal global object is when we enable/disable some features based on which global we are running in:

one is at the beginning of HostLoadImportedModule, where we disallow dynamic import in service workers and worklets. However, in this case you are already using realm's principal realm's global object
the other one is in "resolve a module specifier", where we only allow import maps if the referrer's global object implements Window. This already checks the realm's global and not the realm's principal realm's global.

So again, do we actually need the concept of the current principal global object, or can we continue using the current global object (with the manual handling in HostLoadImportedModule to actually grab the global object of the principal realm)?

the other one is in "resolve a module specifier", where we only allow import maps if the referrer's global object implements Window. This already checks the realm's global and not the realm's principal realm's global.

Is it intentional that ShadowRealms ignore the principal realm's import map?

Ms2ger · 2024-11-20T16:28:28Z

Talking to Nic, it seems that when you need a realm, you're most likely to want to use the (potentially synthetic) current realm, and when you need a settings object, you're most likely to want the current principal settings object. Practically the suggestion is that we'd remove the "current principal realm" definition, and where it's really needed, people can go through the current principal settings object. Any objections to that, @domenic (or others)?

…, a=testonly Automatic update from web-platform-tests Change 'shadowrealm' global into a shorthand for all possible ShadowRealm scopes In order to automatically run tests not only in a ShadowRealm created in a window scope, but also in ShadowRealms created in other realms, change the 'shadowrealm' global type to a collection, and rename the existing ShadowRealm handler to 'shadowrealm-in-window'. -- Remove monkeypatch of globalThis.self in ShadowRealm As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness. -- Factor out JS code that will be common to multiple ShadowRealm handlers We will add multiple ShadowRealm handlers, and they will all need to set up certain global properties. Avoid repeating this code in each handler as well as in idlharness-shadowrealm.js. This should also increase readability, which is good since the ShadowRealm setup code can be confusing. -- Add 'shadowrealm-in-shadowrealm' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-shadowrealm.html variant. The test wrapper creates an outer ShadowRealm, which creates an inner ShadowRealm and runs the tests inside that, relaying the results through the outer ShadowRealm. -- Add 'shadowrealm-in-dedicatedworker' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-dedicatedworker.html variant. The test loads an intermediate .any.worker-shadowrealm.js wrapper into a Worker, and forwards the message port to the Worker's message port so that fetch_tests_from_worker can receive the results. -- Add 'shadowrealm-in-sharedworker' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-sharedworker.html variant. The test loads the same intermediate .any.worker-shadowrealm.js wrapper as .any.shadowrealm-in-dedicatedworker.html, but populates a 'port' variable with the port received from the connect event, instead of calling the global postMessage since that won't work in a SharedWorker. -- Add 'shadowrealm-in-serviceworker' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-serviceworker.html variant. We have to use a slightly different .any.serviceworker-shadowrealm.js wrapper from the wrapper used for the other types of workers, because dynamic import() is forbidden in ServiceWorker scopes. Instead, add a utility function to set up a fakeDynamicImport() function inside the ShadowRealm which uses the fetch adaptor to get the module's source text and evaluate it in the shadowRealm. Also add a case for ServiceWorkers to getPostMessageFunc(), which returns a postMessage() drop-in replacement that broadcasts the message to all clients, since test result messages from the ShadowRealm are not in response to any particular message received by the ServiceWorker. Note '.https.' needs to be added to the test path. -- Add 'shadowrealm-in-audioworklet' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-audioworklet.html variant. The wrapper here is similar to the one for ServiceWorkers, since dynamic import() is also forbidden in worklet scopes. But additionally fetch() is not exposed, so we add a utility function to set up the ability to call the window realm's fetch() through the AudioWorklet's message port. We also add /resources/testharness-shadowrealm-audioworkletprocessor.js to contain most of the AudioWorklet setup boilerplate, so that it isn't written inline in serve.py. Note '.https.' needs to be added to the test path. -- wpt-commits: 9c8db8af89efbe0f67b215af2a6b49e9564e2971, 65a205aea5d02ff5bea7b1a0579287035d02d6c4, eb9c8e7259ef8bd5cca5019c1ca15ccd430e81dc, 3a20c56893472783b5e20c0d61cbb7b7b278cc6d, 7d8458ed291b139307430a102180c9a617d7876e, 42160ae827c863ac6787c8451fe377901c8f0652, 59367bb21d053abb9ed6de3cca5409486816acc9, 60d6c48e5fa76876bc3924b9d6185dfb56c9ab1c wpt-pr: 49108

domenic · 2024-11-21T01:03:57Z

I'm fine adding such guidance, but I don't think it makes sense to only define some subset of concepts; there should be the full matrix of 2x3 concepts available.

nicolo-ribaudo

I'm fine adding such guidance, but I don't think it makes sense to only define some subset of concepts; there should be the full matrix of 2x3 concepts available.

As of today in this PR there are only 4 concepts:

current realm (from ECMAScript)
current principal realm
current principal settings object
current principal global object

The places where it would HTML would have used the "current settings object" are just either to grab the realm from it (i.e. in the modules algorithms), so this PR just uses the "current realm" directly, or to grab the global object (in HostPromiseRejectionTracker), so this PR just grabs it from the "current realm" instead.

As per #9893 (comment), I believe in all current usages of the "current principal global object", except for https://html.spec.whatwg.org/#pause, it would be cleaner (*) to use the "current global object": it probably makes sense to at least re-introduce it.

"cleaner" = they are equivalent because those APIs depend on the DOM, the DOM is not available in ShadowRealm, and thus they are not exposed there. However, the rule of thumb I'm applying is, for example, "if ShadowRealms had their own DOM, should customElements.define define an element in the ShadowRealm itself or in the principal realm?"

source

…, a=testonly Automatic update from web-platform-tests Change 'shadowrealm' global into a shorthand for all possible ShadowRealm scopes In order to automatically run tests not only in a ShadowRealm created in a window scope, but also in ShadowRealms created in other realms, change the 'shadowrealm' global type to a collection, and rename the existing ShadowRealm handler to 'shadowrealm-in-window'. -- Remove monkeypatch of globalThis.self in ShadowRealm As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness. -- Factor out JS code that will be common to multiple ShadowRealm handlers We will add multiple ShadowRealm handlers, and they will all need to set up certain global properties. Avoid repeating this code in each handler as well as in idlharness-shadowrealm.js. This should also increase readability, which is good since the ShadowRealm setup code can be confusing. -- Add 'shadowrealm-in-shadowrealm' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-shadowrealm.html variant. The test wrapper creates an outer ShadowRealm, which creates an inner ShadowRealm and runs the tests inside that, relaying the results through the outer ShadowRealm. -- Add 'shadowrealm-in-dedicatedworker' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-dedicatedworker.html variant. The test loads an intermediate .any.worker-shadowrealm.js wrapper into a Worker, and forwards the message port to the Worker's message port so that fetch_tests_from_worker can receive the results. -- Add 'shadowrealm-in-sharedworker' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-sharedworker.html variant. The test loads the same intermediate .any.worker-shadowrealm.js wrapper as .any.shadowrealm-in-dedicatedworker.html, but populates a 'port' variable with the port received from the connect event, instead of calling the global postMessage since that won't work in a SharedWorker. -- Add 'shadowrealm-in-serviceworker' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-serviceworker.html variant. We have to use a slightly different .any.serviceworker-shadowrealm.js wrapper from the wrapper used for the other types of workers, because dynamic import() is forbidden in ServiceWorker scopes. Instead, add a utility function to set up a fakeDynamicImport() function inside the ShadowRealm which uses the fetch adaptor to get the module's source text and evaluate it in the shadowRealm. Also add a case for ServiceWorkers to getPostMessageFunc(), which returns a postMessage() drop-in replacement that broadcasts the message to all clients, since test result messages from the ShadowRealm are not in response to any particular message received by the ServiceWorker. Note '.https.' needs to be added to the test path. -- Add 'shadowrealm-in-audioworklet' global This will add to any test with global=shadowrealm in its metadata, an .any.shadowrealm-in-audioworklet.html variant. The wrapper here is similar to the one for ServiceWorkers, since dynamic import() is also forbidden in worklet scopes. But additionally fetch() is not exposed, so we add a utility function to set up the ability to call the window realm's fetch() through the AudioWorklet's message port. We also add /resources/testharness-shadowrealm-audioworkletprocessor.js to contain most of the AudioWorklet setup boilerplate, so that it isn't written inline in serve.py. Note '.https.' needs to be added to the test path. -- wpt-commits: 9c8db8af89efbe0f67b215af2a6b49e9564e2971, 65a205aea5d02ff5bea7b1a0579287035d02d6c4, eb9c8e7259ef8bd5cca5019c1ca15ccd430e81dc, 3a20c56893472783b5e20c0d61cbb7b7b278cc6d, 7d8458ed291b139307430a102180c9a617d7876e, 42160ae827c863ac6787c8451fe377901c8f0652, 59367bb21d053abb9ed6de3cca5409486816acc9, 60d6c48e5fa76876bc3924b9d6185dfb56c9ab1c wpt-pr: 49108

shannonbooth · 2024-11-24T21:20:36Z

source

+  <h6>Creating a Shadow Realm</h6>
+
+  <p>When performing <span data-x="js-InitializeHostDefinedRealm">InitializeHostDefinedRealm</span>
+  in the <code data-x="js-ShadowRealm-constructor">ShadowRealm</code> constructor, the steps to


I personally preferred the old steps for global object creation before dc9fddc as the steps if followed explicitly were more easily implementable without needing to add web specific changes into the javascript implementation. There is no clear hook for InitializeHostDefinedRealm to say that it is being invoked in the ShadowRealm constructor.

I think this type of customization should ideally be explicitly stated at the call site of HostInitializeShadowRealm, similar to how https://whatpr.org/html/9893/webappapis.html#creating-a-new-javascript-realm does where it is used like:

Let realm execution context be the result of creating a new realm given agent and the following customizations:

For the global object, create a new Window object.

For the global this binding, use browsingContext's WindowProxy object.

What makes this awkward is that HostInitializeShadowRealm is being invoked in JS spec, where we would like to make that customization.

ptomato · 2024-11-25T20:18:26Z

source

@@ -113690,25 +114036,15 @@ interface mixin <dfn interface>WindowOrWorkerGlobalScope</dfn> {



I guess if we really need to have things conditionally exposed depending on whether the incumbent realm is a secure context, we'll also need to move isSecureContext to UniversalGlobalScope. (2 lines above this)

ptomato · 2024-11-25T20:35:17Z

source

+
+  // structured cloning
+  any <span data-x="dom-structuredClone">structuredClone</span>(any value, optional <span>StructuredSerializeOptions</span> options = {});
+};


This is still missing the event handlers that go along with the universally exposed stuff - onerror, onrejectionhandled, onunhandledrejection.

I'm not sure if they should go here or in ShadowRealmGlobalScope. Adding them here might make things complicated. onerror is part of GlobalEventHandlers which Document also includes. The latter two are part of WindowEventHandlers which HTMLBodyElement also includes. So either we add these to ShadowRealmGlobalScope, or we add them here and remove them from WorkerGlobalScope, GlobalEventHandlers, and WindowEventHandlers, then additionally re-add them to Document, HTMLBodyElement, and anywhere else they're supposed to be included.

(We'll also have to decide whether to have the weird signature that the onerror handler has on Window and Worker globals)

Is there a way to associate / plumb the shadow realm through the unhandled rejection hooks? Unhandled rejections for shadow realm promises cannot be reported in the main realm event because of the callable boundary. I see that HostPromiseRejectionTracker only takes the promise, which may not be sufficient for the host to figure out which realm it belongs to.

Btw, there is still some pending implementation issues about which realm reactions are invoked in, but in the case of ShadowRealm they shouldn't apply since promises in these realms cannot interact with other realms.

I guess technically the host hook can lookup the current realm record.

I'll defer to @Ms2ger but I believe this is handled correctly by the current state of this PR's HostPromiseRejectionTracker. We get the ShadowRealm global from the running script's realm and otherwise from the current realm (although I'm not sure in which case the running script would be null during ShadowRealm execution.)

Ah ok so HTML is already relying on the current realm.

ptomato · 2024-11-25T23:19:20Z

source

@@ -113690,25 +114036,15 @@ interface mixin <dfn interface>WindowOrWorkerGlobalScope</dfn> {

  undefined <span data-x="dom-reportError">reportError</span>(any e);


On review, I think reportError probably meets the criteria to be exposed in w3ctag/design-principles#510. Maybe move this to UniversalGlobalScope unless we have a good reason not to?

Ms2ger mentioned this pull request Oct 30, 2023

JavaScript ShadowRealm proposal integration #5339

Closed

3 tasks

Ms2ger force-pushed the realms branch from d589ac8 to 4a0ccfc Compare October 30, 2023 14:56

mgaudet mentioned this pull request Nov 20, 2023

ShadowRealm Web Platform integration testing and expectations tc39/proposal-shadowrealm#386

Closed

nicolo-ribaudo reviewed Dec 8, 2023

View reviewed changes

source Outdated Show resolved Hide resolved

leobalter mentioned this pull request Jan 22, 2024

[Stage 3] Web APIs to be exposed to ShadowRealms tc39/proposal-shadowrealm#393

Open

49 tasks

Ms2ger marked this pull request as ready for review February 2, 2024 15:10

ptomato mentioned this pull request Feb 7, 2024

Expose AbortSignal.timeout on all globals whatwg/dom#1253

Closed

5 tasks

ptomato mentioned this pull request Feb 12, 2024

Exposed=* vs Exposed=Shadow tc39/proposal-shadowrealm#398

Closed

Ms2ger mentioned this pull request Mar 7, 2024

ShadowRealm API mozilla/standards-positions#997

Open

Ms2ger force-pushed the realms branch from 1edd30b to 591a4b4 Compare September 20, 2024 12:43

Ms2ger mentioned this pull request Sep 25, 2024

Update to HTML changes for ShadowRealms whatwg/webidl#1437

Draft

5 tasks

Ms2ger force-pushed the realms branch 2 times, most recently from 4fd9960 to 9d8d9ec Compare September 26, 2024 13:15

Ms2ger mentioned this pull request Sep 26, 2024

Allow using Crypto.getRandomValues() in Shadow Realms w3c/webcrypto#361

Open

8 tasks

Ms2ger force-pushed the realms branch from 9d8d9ec to c0acec5 Compare September 26, 2024 15:05

lukewarlow reviewed Sep 30, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

lukewarlow reviewed Sep 30, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

lukewarlow reviewed Sep 30, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

ptomato mentioned this pull request Oct 1, 2024

New text for guidance on exposing interfaces everywhere w3ctag/design-principles#510

Open

ptomato reviewed Oct 1, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

ptomato mentioned this pull request Oct 10, 2024

Consider using globalThis in harness code web-platform-tests/wpt#31996

Open

shannonbooth reviewed Oct 21, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

Ms2ger force-pushed the realms branch from df5706b to a67403f Compare October 21, 2024 09:29

shannonbooth reviewed Oct 22, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

shannonbooth reviewed Oct 26, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

Indentation

7660208

ptomato added a commit to ptomato/wpt that referenced this pull request Nov 18, 2024

Remove monkeypatch of globalThis.self in ShadowRealm

f9b4019

As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness.

ptomato added a commit to ptomato/wpt that referenced this pull request Nov 18, 2024

Remove monkeypatch of globalThis.self in ShadowRealm

3098912

As per whatwg/html#9893, ShadowRealmGlobalScope should have a `self` attribute already. There is no need to monkeypatch it for the test harness.

Fix

f5194b0

Remove unnecessary concept

873cd6d

nicolo-ribaudo reviewed Nov 20, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

nicolo-ribaudo reviewed Nov 20, 2024

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

queueing

f896319

Ms2ger added 2 commits November 21, 2024 14:36

Better guidance and sectioning

eff546f

Improve the global object creation

dc9fddc

nicolo-ribaudo reviewed Nov 21, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

nicolo-ribaudo reviewed Nov 21, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

nicolo-ribaudo and others added 3 commits November 21, 2024 15:44

Rephrase

f0e4ee6

address comment

c8d1b45

Note

a12d85e

shannonbooth reviewed Nov 24, 2024

View reviewed changes

ptomato reviewed Nov 25, 2024

View reviewed changes

This was referenced Nov 26, 2024

Add ShadowRealm tests for isSecureContext web-platform-tests/wpt#49365

Open

Enable ShadowRealm testing for ErrorEvent and queueMicrotask web-platform-tests/wpt#49325

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JavaScript ShadowRealm proposal integration #9893

JavaScript ShadowRealm proposal integration #9893

Ms2ger commented Oct 30, 2023 •

edited by pr-preview bot

Loading

nicolo-ribaudo left a comment •

edited

Loading

Ms2ger commented Feb 2, 2024

littledan commented Feb 7, 2024 •

edited

Loading

Ms2ger commented Oct 8, 2024

Ms2ger commented Nov 19, 2024

nicolo-ribaudo commented Nov 20, 2024 •

edited

Loading

nicolo-ribaudo commented Nov 20, 2024 •

edited

Loading

Ms2ger commented Nov 20, 2024

domenic commented Nov 21, 2024

nicolo-ribaudo left a comment

shannonbooth Nov 24, 2024 •

edited

Loading

ptomato Nov 25, 2024

ptomato Nov 25, 2024

ptomato Nov 25, 2024

mhofman Nov 26, 2024

ptomato Nov 26, 2024

mhofman Nov 26, 2024

ptomato Nov 25, 2024

		@@ -113690,25 +114036,15 @@ interface mixin <dfn interface>WindowOrWorkerGlobalScope</dfn> {

		@@ -113690,25 +114036,15 @@ interface mixin <dfn interface>WindowOrWorkerGlobalScope</dfn> {

		undefined <span data-x="dom-reportError">reportError</span>(any e);

JavaScript ShadowRealm proposal integration #9893

Are you sure you want to change the base?

JavaScript ShadowRealm proposal integration #9893

Conversation

Ms2ger commented Oct 30, 2023 • edited by pr-preview bot Loading

nicolo-ribaudo left a comment • edited Loading

Choose a reason for hiding this comment

Ms2ger commented Feb 2, 2024

littledan commented Feb 7, 2024 • edited Loading

Ms2ger commented Oct 8, 2024

Ms2ger commented Nov 19, 2024

nicolo-ribaudo commented Nov 20, 2024 • edited Loading

nicolo-ribaudo commented Nov 20, 2024 • edited Loading

Ms2ger commented Nov 20, 2024

domenic commented Nov 21, 2024

nicolo-ribaudo left a comment

Choose a reason for hiding this comment

shannonbooth Nov 24, 2024 • edited Loading

Choose a reason for hiding this comment

ptomato Nov 25, 2024

Choose a reason for hiding this comment

ptomato Nov 25, 2024

Choose a reason for hiding this comment

ptomato Nov 25, 2024

Choose a reason for hiding this comment

mhofman Nov 26, 2024

Choose a reason for hiding this comment

ptomato Nov 26, 2024

Choose a reason for hiding this comment

mhofman Nov 26, 2024

Choose a reason for hiding this comment

ptomato Nov 25, 2024

Choose a reason for hiding this comment

Ms2ger commented Oct 30, 2023 •

edited by pr-preview bot

Loading

nicolo-ribaudo left a comment •

edited

Loading

littledan commented Feb 7, 2024 •

edited

Loading

nicolo-ribaudo commented Nov 20, 2024 •

edited

Loading

nicolo-ribaudo commented Nov 20, 2024 •

edited

Loading

shannonbooth Nov 24, 2024 •

edited

Loading