1572644 - Support "import" in worklet scripts

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Karl Tomlinson (back Feb 1 :karlt)]

+++ This bug was initially created as a clone of Bug #1473463 +++

ScriptLoader supports fetching module script graphs but currently has a number of main-thread-only characteristics. The approach proposed in bug 1311726 would permit using this from worklet code.

Jon said in https://bugzilla.mozilla.org/show_bug.cgi?id=1290021#c34
"It would be really great if we could reuse some of the code in the script
loader (and would be useful for other efforts, e.g. bug 1308512). This is not
trivial unfortunately. I think it would require factoring out the module
loader into a separate class with a caller-provided a fetch interface passed
in."
This would be bug 1311726.

Andrea said in https://bugzilla.mozilla.org/show_bug.cgi?id=1472324#c1
'we must unify WorkletFetchHandler,
workerinternals::Load/LoadMainScript and mozilla::dom::ScriptLoader.'

Ben said in https://bugzilla.mozilla.org/show_bug.cgi?id=1442776#c1
"Would it not be possible to make worklets and workers completely separate?
Decoupling them seems like it would be nice for maintenance since they are
going to be fairly different."
That probably means that any shared code should be in or near ScriptLoader,
rather than in dom/worklers.

Houdini WG said in
https://github.com/w3c/css-houdini-drafts/issues/506#issuecomment-343276228
"RESOLVED: dynamic import() in worklets is a no-op that returns a rejected
promise (or equivalent after passing thru JS people)"

Web platform tests expect static import to work.
https://github.com/w3c/css-houdini-drafts/issues/506#issuecomment-342796390

Comment 1

[Paul Adenot (:padenot)]

It would be great if we could revisit priorities here. People expect imports to work in AudioWorklet, that we just enabled in Nightly (it's supposed to work per spec, and it works in Chromium). I'm seeing some websites that rely on this. AudioWorklet usage is still not widespread however.

https://superpowered.com/webbrowserlatency
https://mtg.github.io/essentia.js/examples
https://googlechromelabs.github.io/web-audio-samples/audio-worklet/

Comment 2

[Hsin-Yi Tsai [:hsinyi]]

(In reply to Paul Adenot (:padenot) from comment #1)

It would be great if we could revisit priorities here. People expect imports to work in AudioWorklet, that we just enabled in Nightly (it's supposed to work per spec, and it works in Chromium). I'm seeing some websites that rely on this. AudioWorklet usage is still not widespread however.

https://superpowered.com/webbrowserlatency
https://mtg.github.io/essentia.js/examples
https://googlechromelabs.github.io/web-audio-samples/audio-worklet/

Thanks for raising this. Would take to our roadmap planning discussion. :)

Comment 3

[Paul Adenot (:padenot)]

https://ide.csound.com/

Comment 4

[Anne (:annevk)]

Also bringing this to the attention of Adam and Jens.

Comment 5

[johannes.feulner]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #2)

(In reply to Paul Adenot (:padenot) from comment #1)

It would be great if we could revisit priorities here. People expect imports to work in AudioWorklet, that we just enabled in Nightly (it's supposed to work per spec, and it works in Chromium). I'm seeing some websites that rely on this. AudioWorklet usage is still not widespread however.

Here is one more Website using WASM in AudioWorklet: https://ssc.scorio.com/localtest.html

Comment 6

[hjack]

I'm part of a team using WASM in AudioWorklets, via Superpowered, and would greatly appreciate this feature! We are trying to add Mozilla support and facing complications because import is not supported.

http://samples.landr.com/

Comment 7

[Jack Atherton]

I'm not sure if this is the right place for this.

Webchuck (ChucK in the browser) could also benefit from the ability to "import" in the AudioWorklet.

This version works in Chrome but not Firefox, exhibiting the "Module resolve hook not set" error message.

As suggested in 1636121, I've made a version that uses --extern-post-js to avoid the use of any imports. This faces the new bug "Module metadata hook not set", for which I haven't found any useful workarounds / bug reports.

This version works in Chrome but not Firefox, exhibiting the new bug. I'm not sure if this is completely unrelated, or if I've done something wrong in my attempt to eliminate import statements / ES6. Perhaps I can't use the -s MODULARIZE=1 option in Emscripten, even though I'm not using it alongside import statements?

Comment 8

[Jack Atherton]

It turns out I made a very silly mistake and did not remove the flag that was enabling ES6 support. I was able to flatten all of the imports, etc. into a single extern-post-js file, and things seem to work now. Here's the command that seems to be working for ChucK in Firefox, in case it helps anyone else facing this bug:

host_web/webchuck/js/webchuck.js: $(EMSCRIPTENSRCS)
	emcc -O3 -s DISABLE_EXCEPTION_CATCHING=0 \
        [many flags related to ChucK internals]
	-Wformat=0 \
        $(EMSCRIPTENSRCS) -o host_web/webchuck/js/webchuck.js \
        -s EXTRA_EXPORTED_RUNTIME_METHODS='["ccall", "cwrap", "getValue", "setValue", "addFunction", "removeFunction", "UTF8ToString", "stringToUTF8"]' \
        -s LINKABLE=1 -s MODULARIZE=1 -s 'EXPORT_NAME="ChucK"' \
        -s ALLOW_MEMORY_GROWTH=1 \
        -s --extern-post-js host_web/chucknode-postjs.js \
        -s RESERVED_FUNCTION_POINTERS=50 -s FORCE_FILESYSTEM=1

Comment 9

[Anne (:annevk)]

Clearing needinfos in favor of bug 1311726 comment 2 as that bug is the main thing that needs fixing here as I understand it.

Comment 10

[Maxime Chevalier-Boisvert]

Hello. I got here because I also stumbled upon this bug while trying to build a modular-synth-in-a-browser app that uses AudioWorklet. ES6 support in AudioWorklet would be much appreciated :)