1469992 - Firefox doesn't have mimetype for webassembly

Status: RESOLVED WONTFIX

(Firefox :: File Handling, defect, P5)

Description

[Michael Droettboom [:mdroettboom]]

When loading WebAssembly binaries from the local filesystem or a WebExtension, it can not be compiled using WebAssembly.compileStreaming because the mimetype does not match `application/wasm`.  See [1] for the relevant bit of the WebAssembly spec.

Should it perhaps be added to the list of hardcoded mimetypes here? 

https://dxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#463

[1] https://www.w3.org/TR/wasm-web-api-1/#streaming-modules

Comment 1

[Sarah Bird]

Here is an example of an addon that needs firefox to know about webassembly mime type - https://addons.mozilla.org/en-US/firefox/addon/pyconsole/

On linux this is easy enough to work around. On OSX I have not yet found a way.

Comment 2

[:Paolo Amadini]

I'm not sure if we should have a default MIME type for this extension, which may affect also the general case of remote downloads. Michael, can you describe what is the issue here, and is there a workaround that can be applied elsewhere? How does this relate to bug 1470182?

Comment 3

[Michael Droettboom [:mdroettboom]]

Issue #1 is that you can not create a WebExtension that uses the streaming API (WebAssembly.compile) to load WebAssembly bytecode.  As :callahad pointed out elsewhere [1], you can work around this by using the non-streaming API.

[1] https://github.com/birdsarah/pyodide/pull/1

Issue #2 is you can't load an application from the local filesystem (if the OS doesn't have `application/wasm` in its mime database, which recent versions of Fedora/Ubuntu/Debian at the time of this writing do not).  This can be worked around by serving the application from a local webserver instead (and also configuring the webserver about the mimetype).

Now that we've found the workaround to #1, I'd say this behavior is merely surprising at worst.  And I assume #2 (maybe #1 also) will resolve itself in time as MIME databases are updated with `application/wasm` and make it out to clients.  (I don't know how these transitions have gone for other new MIME types in the past...)

I think bug 1470182 is fundamentally just a dupe of #1 -- with the suggested solution to do something WebExtension specific to solve the issue, rather than the suggestion here to add it to the set of hardcoded mimetypes globally.

Comment 4

[:Paolo Amadini]

Since there are workarounds, and part of this issue is already tracked by bug 1470182, adding the extension to the hardcoded list doesn't seem necessary at the moment. We can always reopen the bug if we later find that this is the best solution.