Open Bug 1540913 Opened 9 months ago Updated Yesterday

Dynamic module import doesn't work in a worker

Categories

(Core :: DOM: Workers, enhancement, P3)

67 Branch
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: tim57282, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Attempting to import an ES6 module inside a worker fails with "SyntaxError: dynamic module import is not implemented".
javascript.options.dynamicImport is set to true, and import works outside of a worker.

The code looks like this:
import("path_to_file_on_same_server").then(function() {
//do stuff
});

The worker is created like:
var worker=new Worker("filename_of_worker.js");

This works on Chrome (only tested 75).

An I doing something wrong? Is this not implemented/supported?

Actual results:

Threw an error: "SyntaxError: dynamic module import is not implemented"

Expected results:

No error, the module is loaded.

Maybe related to Bug 1536094?

This is a bit to advanced for me to reproduce but I think the component for it is Core DOM: Core & HTML, If not please change the component to a more suitable one.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Component: DOM: Core & HTML → DOM: Workers

I don't think this is implemented for Workers (so unfortunately MDN may be a little inaccurate). The dynamic import tests for Workers are are expected failures, too (e.g. https://searchfox.org/mozilla-central/source/testing/web-platform/meta/workers/modules/dedicated-worker-import.any.js.ini).

Priority: -- → P3

(In reply to Perry Jiang [:perry] from comment #3)

I don't think this is implemented for Workers (so unfortunately MDN may be a little inaccurate). The dynamic import tests for Workers are are expected failures, too (e.g. https://searchfox.org/mozilla-central/source/testing/web-platform/meta/workers/modules/dedicated-worker-import.any.js.ini).

Yeah I figured that was the case, but I didn't find a bug to implement this, so I opened this one.

So is there any movement/progress/interest in this?
Emscripten relies on dynamic module import in a worker for it's ES6 Module + pthreads + WASM implementation, so it would be nice if this wasn't Chrome exclusive.

In the meantime, would it be possible to make this a runtime error rather than a syntax error, so that it's possible to if/else or try/catch around it? Currently, any worker script with import() in it fails to load completely, so using it in a backwards-compatible way (or even detecting support) would require eval, which is not ideal.

Jon, do you know what's involved in making import() work in web workers?

Component: DOM: Workers → JavaScript Engine
Depends on: 1342012
Flags: needinfo?(jcoppeard)
Priority: P3 → --

(In reply to Andrew Overholt [:overholt] from comment #7)

Jon, do you know what's involved in making import() work in web workers?

Currently, the module loading is supported only on the main thread. When loading a module, it can require the "sync" loading of submodules. This involves network operations and script parsing. So far, this is supported only on the main thread because it's strongly connected with the <script> element. If we want to support modules in workers, we need to take out the networking part and make it able to run on workers.

Alternatively, we can have an intermediate step, in which we support modules, but we don't allow "import". We do something similar in worklets.

Indeed. There's a separate script loader for workers and as baku says networking is also different on workers (I don't know the details). So this requires factoring the current implementation out of the main thread script loader and integrating it into the worker script loader. It's quite a lot of work.

Flags: needinfo?(jcoppeard)

Thank you for clarifying, baku and jonco. In the meantime, can we do as comment 6 suggests?

Component: JavaScript Engine → DOM: Workers

(In reply to Andrew Overholt [:overholt] from comment #10)
Sure. I've filed bug 1580536.

(In reply to Jon Coppeard (:jonco) from comment #11)

(In reply to Andrew Overholt [:overholt] from comment #10)
Sure. I've filed bug 1580536.

Let's take this as an enhancement and put into our backlog

Type: defect → enhancement
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.