Sporadic "importScripts" failures

103 views
Skip to first unread message

Tim Pillard

unread,
Aug 29, 2025, 11:36:38 AM (6 days ago) Aug 29
to Chromium Extensions
Hi,

We use "importScripts" in our Extension's Service Worker in two cases:
1. as part of bundling our extension's service worker
2. to preload a script that's needed later

We notice in our exception logs the script preloading is sporadically (up to a couple hundred times per day) failing - but have no indication of the other importScripts failing:

"Failed to execute 'importScripts' on 'WorkerGlobalScope': Failed to import 'chrome-extension://.../assets/some/script.min.js'. importScripts() of new scripts after service worker installation is not allowed."

"Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at 'chrome-extension://.../assets/some/script.min.js' failed to load."

This use of importScripts is in the critical initialization path of our service worker.

Is anyone seeing something similar?
Am I missing a best practice on the use of importScripts?

Oliver Dunk

unread,
Aug 29, 2025, 11:42:25 AM (6 days ago) Aug 29
to Tim Pillard, Chromium Extensions
Hi Tim,

This use of importScripts is in the critical initialization path of our service worker.

Could you clarify what this means?

It needs to run almost immediately, and definitely before any async code in the service worker. Usually putting the import at the top-level of your file is the safest approach. Some nesting can be ok, but it is easy to get wrong.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB


--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/90c03132-73c7-47ca-ba05-ccea70cf40e6n%40chromium.org.

Tim Pillard

unread,
Aug 29, 2025, 12:36:28 PM (6 days ago) Aug 29
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Tim Pillard
Hi Oliver,
Thank you for the quick reply.


This use of importScripts is in the critical initialization path of our service worker.

> Could you clarify what this means?

I mean this import is necessary for our extension to function, and an exception throwing at this level will prevent further initialization of our service worker script.


> It needs to run almost immediately, and definitely before any async code in the service worker. Usually putting the import at the top-level of your file is the safest approach. Some nesting can be ok, but it is easy to get wrong.

It's in a synchronous code path but technically not at the top of the file, rather pretty far down, there are dozens of function calls, uncluding async code before it.
Do you recommend I try to move this import as high as possible to heir on the safe side? Or should I use a oninstall event listener?

Oliver Dunk

unread,
Aug 29, 2025, 1:09:42 PM (6 days ago) Aug 29
to Tim Pillard, Chromium Extensions
It's in a synchronous code path but technically not at the top of the file, rather pretty far down, there are dozens of function calls, uncluding async code before it.

Yes, that would definitely be good. As the error mentions, after service worker installation importing new scripts isn't allowed so it could definitely lead to problems.

Listening for the install event would probably work well, but I don't find that gets used much in extensions and so personally I would just put the import at the very top of the file if possible.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

woxxom

unread,
Aug 30, 2025, 4:00:21 PM (5 days ago) Aug 30
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Tim Pillard
You can use importScripts asynchronously as explained in https://stackoverflow.com/a/66408379, section "Dynamic importScripts".

The workaround is quite inconvenient so hopefully a dynamic import() is implemented soon or maybe the team realizes that choosing service worker was always a mistake made by core C++ developers who had no meaningful experience developing nontrivial extensions. A possible easily implementable alternative might be a shared worker which will soon allow its lifetime to be handled independently of associated documents, see https://github.com/whatwg/html/issues/10997, already supported in Chromium via origin trials https://developer.chrome.com/origintrials/#/view_trial/3056255297124302849

Reply all
Reply to author
Forward
0 new messages