-
Notifications
You must be signed in to change notification settings - Fork 23k
TrustedTypes: WorkerGlobalScope: importScripts() #42396
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
base: main
Are you sure you want to change the base?
Conversation
|
Preview URLs (comment last updated: 2025-12-16 03:50:26) |
1df9d6b to
848dbd0
Compare
|
|
||
| {{APIRef("Web Workers API")}}{{AvailableInWorkers("worker")}} | ||
|
|
||
| > [!WARNING] |
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.
@wbamberg This follows same pattern as the others. The method is used to import (one or more) classic scripts into a classic module.
I have done quite a lot of testing.
- FF will silently fail to load a worker or import a script with UTF-16 encoding. The web prefers UTF8 but the fact this fails silently is irritating, because I assumed my files would default to UTF8.
- Do you (also) think a BCD note on the worker itself makes sense?
- Both the initial script and subsequent importScript operation appear to be fetched in no-cors mode.
- BUT from my testing the initial script MUST be same-origin with the worker or a blob or data type.
- I expected same-origin importScript to work, and it does.
- Not entirely sure what I exected for importScript cross origin, but it seems to work fine - or at least a console.log() in the loaded script runs. That's with no special headers or settings on either server.
- You can block the load by having a CORP on the cross-origin file to be loaded.
- However if you add a CSP for the worker-src it seem to be ignored for the nested importScript (though it obeys it for the top level import in that you can set
none. That's my testing anyway.
Essentially it looks like for this method you can import what you like from wherever you like unless blocked by the server resource policy you are importing from.
FYI, my testing is here https://github.com/hamishwillee/various_webapi_tests/tree/main/classic_worker_import - this uses a caddyfile - caddy allows you to set up a server with headers, https and certificate with no real effort..
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.
PS I have not tried to capture all that in this doc. Waiting to see your thoughts.
|
|
||
| The **`importScripts()`** method synchronously imports one or more scripts into the worker's scope. | ||
|
|
||
| Unlike the initial classic module script, which must be same-origin with its document, this method can import scripts that are cross-origin unless blocked by a resource {{httpheader("Cross-Origin-Resource-Policy")}} or some other security mechanism. |
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.
This is where I'd add a bit more on the importing rules for classic scripts https://github.com/mdn/content/pull/42396/files#r2621680224
WorkerGlobalScope.importScripts()takes any number of trusted script URL. parameters. This updates the docs to reflect that the scriptURL can be a trusted type.(it mirrors #42362)
Still working on it - cursed imports.
Related docs work can be tracked in:
document.write()/document.writeln()#37518