-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Run ShadowRealm tests in multiple scopes #49108
Open
ptomato
wants to merge
7
commits into
web-platform-tests:master
Choose a base branch
from
ptomato:48573-run-shadowrealm-tests-in-multiple-scopes
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Run ShadowRealm tests in multiple scopes #49108
ptomato
wants to merge
7
commits into
web-platform-tests:master
from
ptomato:48573-run-shadowrealm-tests-in-multiple-scopes
+455
−32
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpt-pr-bot
requested review from
DanielRyanSmith,
foolip,
jgraham and
sideshowbarker
November 11, 2024 21:13
…ealm 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'.
We will add multiple ShadowRealm handlers, and they will all need to set up certain global properties. Avoid repeating this code in each handler. This should also increase readability, which is good since the ShadowRealm setup code can be confusing.
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.
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.
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.
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.
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.
ptomato
force-pushed
the
48573-run-shadowrealm-tests-in-multiple-scopes
branch
from
November 14, 2024 22:13
399d528
to
a3e8bc7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a bunch of new global scopes to run ShadowRealm tests inside ShadowRealms hosted in multiple scopes: window, workers, AudioWorklet, and another ShadowRealm.
global=shadowrealm
is now an alias for all of these scopes. The purpose is to catch more potential bugs and exercise different codepaths in implementations, compared to the status quo of only testing in a ShadowRealm hosted in a window scope.Closes: #48573