Skip to content

Conversation

@hamishwillee
Copy link
Collaborator

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:

@github-actions github-actions bot added the Content:WebAPI Web API docs label Dec 15, 2025
@github-actions github-actions bot added the size/s [PR only] 6-50 LoC changed label Dec 15, 2025
@github-actions
Copy link
Contributor

github-actions bot commented Dec 15, 2025

Preview URLs

(comment last updated: 2025-12-16 03:50:26)

@github-actions github-actions bot added size/m [PR only] 51-500 LoC changed and removed size/s [PR only] 6-50 LoC changed labels Dec 16, 2025
@hamishwillee hamishwillee marked this pull request as ready for review December 16, 2025 03:48
@hamishwillee hamishwillee requested a review from a team as a code owner December 16, 2025 03:48

{{APIRef("Web Workers API")}}{{AvailableInWorkers("worker")}}

> [!WARNING]
Copy link
Collaborator Author

@hamishwillee hamishwillee Dec 16, 2025

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.

  1. 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?
  2. Both the initial script and subsequent importScript operation appear to be fetched in no-cors mode.
  3. BUT from my testing the initial script MUST be same-origin with the worker or a blob or data type.
  4. I expected same-origin importScript to work, and it does.
  5. 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.
  6. You can block the load by having a CORP on the cross-origin file to be loaded.
  7. 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..

Copy link
Collaborator Author

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.
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant