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

…, 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.

Yeah, it's not great in terms of layering. I'm hoping tc39/ecma262#3497 and tc39/ecma262#3274 will get us somewhere better, and then we can do an editorial change to adjust to that.

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 UltraBlame original commit: 0a625225a525e60a048bbd6f3a94e2605c7e375b

shannonbooth · 2024-11-27T10:28:40Z

source

@@ -111504,7 +111504,8 @@ interface <dfn interface>ShadowRealmGlobalScope</dfn> : <span>EventTarget</span>

   <li><p>Set <var>settings</var>'s <span
   data-x="synthetic-realm-settings-object-principal-realm">principal realm</span> to <var>O</var>'s
-   <span>associated realm</span>.</p></li>
+   <span>associated realm</span>'s
+   <span data-x="concept-principal-realm-of-realm">principal realm</span>.</p></li>


Could we still run into an issue here if there is a third layer of shadow realm nesting?

My thinking is that this should effectively be a while loop which will go up until it sees that the host defined is not a synthetic settings object. Then, principal-realm-of-realm does not need to worry about how many layers of nesting of shadow realms there are.

Suppose a principal realm X → ShadowRealm A → ShadowRealm B → ShadowRealm C.

Creating A: O's associated realm is X, so we set A.[[HostDefined]]'s synthetic-realm-settings-object-principal-realm to X's concept-principal-realm-of-realm which is also X

Creating B: O's associated realm is A, and A's concept-principal-realm-of-realm is A.[[HostDefined]]'s synthetic-realm-settings-object-principal-realm, which is X, and we set B.[[HostDefined]]'s synthetic-realm-settings-object-principal-realm to X.

Creating C: O's associated realm is B, and B's concept-principal-realm-of-realm is B.[[HostDefined]]'s synthetic-realm-settings-object-principal-realm, which is X, etc.

…, 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

…, 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 UltraBlame original commit: 6e028bd2e67651237d696535280054f7c544f251

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

Merged

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

shannonbooth reviewed Nov 24, 2024

View reviewed changes

ptomato reviewed Nov 25, 2024

View reviewed changes

source Show resolved Hide resolved

ptomato reviewed Nov 25, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

ptomato reviewed Nov 25, 2024

View reviewed changes

source Show resolved Hide resolved

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

Ms2ger added 4 commits November 26, 2024 10:17

link ShadowRealmGlobalScope

2039fa1

event handlers

0f65b04

Add reportError

9aece76

isSecureContext

8cf3150

shannonbooth reviewed Nov 26, 2024

View reviewed changes

source Show resolved Hide resolved

Ms2ger added 2 commits November 27, 2024 09:31

Fix base url in module specifier resolution

acb7665

Fix HostInitializeShadowRealm

7449ee0

shannonbooth reviewed Nov 27, 2024

View reviewed changes

Ms2ger mentioned this pull request Nov 27, 2024

change: Update 'relative high resolution time' to use the principal realm. w3c/hr-time#168

Draft

4 tasks

relevant principal *

a2fe477

nicolo-ribaudo mentioned this pull request Nov 27, 2024

Upcoming WHATNOT meeting on 2024-11-28 #10789

Closed

ptomato mentioned this pull request Dec 3, 2024

ShadowRealm (including HTML integration) WebKit/standards-positions#433

Open

past added the needs implementer interest Moving the issue forward requires implementers to express interest label Dec 5, 2024

past mentioned this pull request Dec 5, 2024

Upcoming WHATNOT meeting on 2024-12-05 #10805

Closed

past mentioned this pull request Dec 13, 2024

Upcoming WHATNOT meeting on 2024-12-12 #10825

Closed

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

shannonbooth Nov 24, 2024 •

edited

Loading

Ms2ger Nov 26, 2024

shannonbooth Nov 27, 2024

Ms2ger Nov 27, 2024

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

shannonbooth Nov 24, 2024 • edited Loading

Choose a reason for hiding this comment

Ms2ger Nov 26, 2024

Choose a reason for hiding this comment

shannonbooth Nov 27, 2024

Choose a reason for hiding this comment

Ms2ger Nov 27, 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

shannonbooth Nov 24, 2024 •

edited

Loading