Does this actually need JS engine changes?

No, all the work is in the embedding.

Chromium will send an intent to ship ES modules for Shared Workers.
(crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=824646)

We are considering FireFox is positive for supporting this feature since the specification discussion (https://github.com/whatwg/html/pull/608#issuecomment-183003447).
If there is misunderstanding or any updates, please let us know.

As part of overhauling the scriptloader to support modules we'd also like to try and reduce code duplication between the worker scriptloader and the main-thread window scriptloader. Much of the complexity in the worker scriptloader relates to 2 things:

1. Channels can't be opened on worker threads. Bug 1528285 will address this so we want to wait on that.
2. Loading ServiceWorker scripts from Cache API storage does not look like using a channel. For this, a tentative plan to investigate is to create a dedicated channel type for loading scripts from the Cache API. This could help normalize things from the script loader's perspective.
   • This may or may not also dovetail with the need for there to be a Worker equivalent to DocumentChannel for ServiceWorker and SharedWorker cases where we need to know the COEP header value before we select the process to spin up the worker.

Chromium Status: Fixed
https://bugs.chromium.org/p/chromium/issues/detail?id=824647

Webkit Status: Fixed
https://bugs.webkit.org/show_bug.cgi?id=164860

Both will ship soon!

A quick update on this ticket would be appreciated!

The missing JS module support still affects the neo.mjs framework dev mode.
This one now runs fine in Chrome as well as Safari Tech Preview, while FF can only use the dist versions.

I got invited into the working draft podcast this evening to talk about workers.
So far I can only say: "No clue if and when this will happen for FF", which feels bad.

Thx for your input!
Tobias

I am currently working on the dependency (https://bugzilla.mozilla.org/show_bug.cgi?id=1311726), so this work should follow shortly. The prep work is pretty tricky. It will happen, can't give an absolute time estimate right now.

Hi Yulia, thanks for the fast response! Very much appreciated.

As a dev, I would never ask other devs for absolute time estimates :)
It sounds great, that this ticket is finally getting picked up.

In case you need some rather complex testing scenarios, feel free to use the dev version of the neo online examples:
https://neomjs.github.io/pages/node_modules/neo.mjs/dist/production/apps/website/index.html#mainview=examples&childview=devmode

Best regards,
Tobias

Yulia: thanks for the last update on this! May I ask if "this work should follow shortly" is still accurate?
https://bugzilla.mozilla.org/show_bug.cgi?id=1311726 also references import maps, and I'd understand if that's more important.

I want to encourage/contribute to bundlers to improve their worker support by treating new Worker(new URL("./file.js"), import.meta.url)) similar to a dynamic import in their dependency graph. Library authors like me currently have to work around a lot of issues, but module workers would solve a lot of them.
(I don't want to gripe too much, but I'm speaking from a lot of experience. I've spent literally hundreds of hours finding hacks so that I can provide web worker libraries that are compatible across common JS environments: https://github.com/lgarron/web-worker-compat-problems)

Unfortunately, I think it will hard to get bundlers to do something until Firefox at least experimentally supports module workers, because it's very hard to transpile ESM to something that works in classic workers. It's really valuable if module workers are available in the stable versions of all modern browsers, and Firefox will soon be the only one without support: https://caniuse.com/?search=module%20worker
For example, Snowpack explicitly states:

ESM syntax (import/export) in Web Workers is still not supported in all modern browsers. Snowpack v3.0.0 and the Snowpack Webpack v5 plugin will both support automatic bundling once released.
https://www.snowpack.dev/guides/web-worker/

Is there something that contributors can do to help, if we don't have a lot of knowledge of the Firefox codebase?

I've started work on a contribution to esbuild (for
https://github.com/evanw/esbuild/issues/312) to automatically handle new Worker(new URL("./file.js", import.meta.url)) but this will definitely rely on module worker support.

It seems iOS 15 is shipping in 4 days, at which point Firefox will unfortunately be the only modern browser that requires projects to maintain workarounds for classic modules. 😭

Could I ask again whether we can still hope for Firefox to support module workers in the near future? 🥺

Bug 1311726 seems active, which is currently a blocker of this feature.

Depends on D134050

Depends on D134051

Depends on D134052

Big Ups for this magnificent enhancement. Hope its going well.

Depends on D146305

Depends on D147313

Depends on D147314

Depends on D147315

Depends on D147316

Depends on D147317

Depends on D147318

Depends on D147319

Depends on D147320

Depends on D147321

Depends on D147322

Depends on D147323

Depends on D147324

Depends on D134052

Depends on D147326

Depends on D147327

Depends on D147328

Comment on attachment 9278178 [details]
WIP: Bug 1247687 - Implement IsTopLevel to handle cases where we have a child module

Revision D147319 was moved to bug 1784457. Setting attachment 9278178 [details] to obsolete.

Comment on attachment 9278182 [details]
WIP: Bug 1247687 - Make ModuleLoaderBase thread-insensitive

Revision D147323 was moved to bug 1784477. Setting attachment 9278182 [details] to obsolete.

Comment on attachment 9278175 [details]
WIP: Bug 1247687 - Move mClientInfo and mController to the WorkerScriptLoader constructor

Revision D147316 was moved to bug 1784476. Setting attachment 9278175 [details] to obsolete.

Comment on attachment 9278176 [details]
WIP: Bug 1247687 - Make ClientInfo persistant for main scripts on WorkerScriptLoader

Revision D147317 was moved to bug 1784476. Setting attachment 9278176 [details] to obsolete.

Comment on attachment 9278177 [details]
WIP: Bug 1247687 - Move creation of ScriptLoadRequests into own functions

Revision D147318 was moved to bug 1784482. Setting attachment 9278177 [details] to obsolete.

Comment on attachment 9278181 [details]
WIP: Bug 1247687 - Move shutdown operation to be always after ProcessRequests

Revision D147322 was moved to bug 1784482. Setting attachment 9278181 [details] to obsolete.

Comment on attachment 9278184 [details]
WIP: Bug 1247687 - Implement corrected base URI for module redirection

Revision D147325 was moved to bug 1784482. Setting attachment 9278184 [details] to obsolete.

Comment on attachment 9278180 [details]
WIP: Bug 1247687 - Implement single script loading for main script

Revision D147321 was moved to bug 1784482. Setting attachment 9278180 [details] to obsolete.

Comment on attachment 9278172 [details]
WIP: Bug 1247687 - Implement ScriptLoaderInterface Skeleton in WorkerScriptLoader

Revision D147313 was moved to bug 1784481. Setting attachment 9278172 [details] to obsolete.

Comment on attachment 9278173 [details]
WIP: Bug 1247687 - Use ScriptLoaderInterface method for reporting errors

Revision D147314 was moved to bug 1784481. Setting attachment 9278173 [details] to obsolete.

Comment on attachment 9278174 [details]
WIP: Bug 1247687 - Use ScriptLoaderInterface method for filling compile options

Revision D147315 was moved to bug 1784481. Setting attachment 9278174 [details] to obsolete.

Depends on D147327

There is a follow on that needs to implement the csp correctly, and also update the wpt tests. I'm
running those now. I will likely flag workers off initially, so that I can land the csp for workers
separately, unless this isn't seen as a major blocker.

Depends on D155566

This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish after the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.

Depends on D155567

Depends on D155567

Depends on D155568

Depends on D155691

Depends on D155567

Depends on D155691

Depends on D155692

Depends on D156102

Depends on D156102

Depends on D162741

Depends on D162742

Depends on D156103

Depends on D163238

Depends on D156103

Comment on attachment 9292502 [details]
WIP: Bug 1247687 - Implement modules for shared workers

Revision D156103 was moved to bug 1805676. Setting attachment 9292502 [details] to obsolete.

Comment on attachment 9308022 [details]
WIP: Bug 1247687 - Update WPT tests for shared module workers

Revision D164573 was moved to bug 1805676. Setting attachment 9308022 [details] to obsolete.

Comment on attachment 9304751 [details]
WIP: Bug 1247687 - wip service workers

Revision D162744 was moved to bug 1360870. Setting attachment 9304751 [details] to obsolete.

https://hg.mozilla.org/mozilla-central/rev/85b827971a48
https://hg.mozilla.org/mozilla-central/rev/34680059b9f0
https://hg.mozilla.org/mozilla-central/rev/4b0a4fcc6894
https://hg.mozilla.org/mozilla-central/rev/6c129bd72b61
https://hg.mozilla.org/mozilla-central/rev/6ee318df6641
https://hg.mozilla.org/mozilla-central/rev/9276c7e1ddd9
https://hg.mozilla.org/mozilla-central/rev/4dbd510fb042
https://hg.mozilla.org/mozilla-central/rev/e7b103c79b1a
https://hg.mozilla.org/mozilla-central/rev/0c9650a1ac48
https://hg.mozilla.org/mozilla-central/rev/40b8abaf1c0b
https://hg.mozilla.org/mozilla-central/rev/354711cf113a
https://hg.mozilla.org/mozilla-central/rev/55f13fb4ee3f
https://hg.mozilla.org/mozilla-central/rev/2429599729cb
https://hg.mozilla.org/mozilla-central/rev/5d05ab0c7cde
https://hg.mozilla.org/mozilla-central/rev/c6c5750cf713
https://hg.mozilla.org/mozilla-central/rev/721f612fd09f

Backed out for frequent string bundle related crashes with PDF viewer (bug 1806064)

• backout: https://hg.mozilla.org/mozilla-central/rev/59c15c902a18e4ba5998f9dc6235c226cf58bc9a

Backed out as requested by dev

Backout link: https://hg.mozilla.org/integration/autoland/rev/f9b5254f197d58ff78f9388e7dfa4e060cd5463e

https://hg.mozilla.org/mozilla-central/rev/87b6a9494bfb
https://hg.mozilla.org/mozilla-central/rev/ebeb65b42212
https://hg.mozilla.org/mozilla-central/rev/997e9ca2e1e9
https://hg.mozilla.org/mozilla-central/rev/15eb9daca661
https://hg.mozilla.org/mozilla-central/rev/474668f6615e
https://hg.mozilla.org/mozilla-central/rev/7327e6438343
https://hg.mozilla.org/mozilla-central/rev/f3204b9ec0dc
https://hg.mozilla.org/mozilla-central/rev/c585aea29f0c
https://hg.mozilla.org/mozilla-central/rev/a1900e8b640c
https://hg.mozilla.org/mozilla-central/rev/78addb6af24d
https://hg.mozilla.org/mozilla-central/rev/98a751f6f41d
https://hg.mozilla.org/mozilla-central/rev/9e97be53fb49
https://hg.mozilla.org/mozilla-central/rev/060c0649c2f5
https://hg.mozilla.org/mozilla-central/rev/cb4aa6f21ff7
https://hg.mozilla.org/mozilla-central/rev/ad56233b442a

FF111 MDN docs work for this can be tracked in mdn#24402. Essentially this is a release note and an update to browser compatibility data.