1500710 - JAR protocol handler doesn't set WASM mimetype, breaks WebAssembly.instantiateStreaming

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[lukas.lueg]

Attachment: macro_railroad_ext.wasm

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36

Steps to reproduce:

I have written a WebExtension that loads a WASM-module. This works fine on Chrome and Firefox 62 for MacOS, yet on Firefox 62 for Linux and Firefox Nightly for Linux loading the WASM-module fails with an "<unavailable>" error.

The WASM-module is loaded by Rust's `stdweb` package using the generated shim:

 );

            var wasm_instance = ( typeof WebAssembly.instantiateStreaming === "function"
                ? WebAssembly.instantiateStreaming( file, instance.imports )
                    .then( function( result ) { return result.instance; } )

                : file
                    .then( function( response ) { return response.arrayBuffer(); } )
                    .then( function( bytes ) { return WebAssembly.compile( bytes ); } )
                    .then( function( mod ) { return WebAssembly.instantiate( mod, instance.imports ) } ) );

            return wasm_instance
                .then( function( wasm_instance ) {
                    var exports = instance.initialize( wasm_instance );
                    //console.log( "Finished loading Rust wasm module 'macro_railroad_ext'" );
                    return exports;
                })
                .catch( function( error ) {
                    console.log( "Error loading Rust wasm module 'macro_railroad_ext':", error );
                    throw error;
                });


Actual results:

This code fails with the error "<unavailable>".

wasm-verify finds no problems. Setting the CSP or an ID in the manifest does not help. I have no idea how to debug this further and will provide more info if needed. The entire code is at https://github.com/lukaslueg/macro_railroad_ext


Expected results:

The WASM-module should load

Comment 1

[Tooru Fujisawa [:arai]]

sounds like an issue related to sandbox

where's the loader code, and where's the wasm file (or binary?)

any chance that the loader is inside content script (content process) and wasm file is somewhere in file system?
in that case it may fail depends on the permission of the content process.

Comment 2

[lukas.lueg]

The loader is a JS in content_scripts, the wasm-file is part of web_accessible_resources. I fetch the wasm-file using `fetch( chrome.runtime.getURL( "wasm/macro_railroad_ext.wasm" ), {credentials: "same-origin"} )`. This works fine in Firefox on MacOS.

Comment 3

[Tooru Fujisawa [:arai]]

can you provide the steps to reproduce with your extension?

Comment 4

[lukas.lueg]

Attachment: WebExtension which fails to load WASM-module

Comment 5

[lukas.lueg]

I've attached the extension as it is, as it fails on Linux; the entire code is in the link above. Simply load it as a temporary add-on. With the extension loaded, go to https://doc.rust-lang.org/ or https://docs.rs/ which should cause the extension to load. For me the shim fails with printing "Error loading Rust wasm module '...': <unavailable>" to the console. If the extension successfully loads, a message `macro_railroad_ext built .....` is written to the console and https://docs.rs/nom/4.1.1/nom/macro.add_return_error.html will display an image under "Show declaration".

Comment 6

[Tooru Fujisawa [:arai]]

it shows the following error in web console:

  Error loading Rust wasm module 'macro_railroad_ext': TypeError: "Response has unsupported MIME type"
  at macro_railroad_ext.js:46:21

​both on macOS and linux, with 62.0.3 and Nightly 64.0a1 (2018-10-20) (64-bit), with clean profile

I guess it's because the content-type is "application/x-unknown-content-type" for me.

can you provide the exact error message you get?

Comment 7

[lukas.lueg]

The entire message is "Error loading Rust wasm module 'macro_railroad_ext': <unavailable> macro_railroad_ext.js:46:21 ", which refers to the code pasted above. Tested on a clean profile with the zip I attached above.

I'm sorry that I can't provide better info, I would not know how to debug this further myself. I'm setting up a few VMs to retest this.

Comment 8

[Tooru Fujisawa [:arai]]

what happens if you modify the "console.log" line above to the following?

  console.log( "Error loading Rust wasm module 'macro_railroad_ext':", error.toString() );

the "<unavailable>" appears when it fails to clone the passed object.
if the issue happens when passing to console.log, converting the error object to string might give you better info.

Comment 9

[lukas.lueg]

Fails on Ubuntu 18.10 with 63 also. The error.toString() is "Error loading Rust wasm module 'macro_railroad_ext': TypeError: Response has unsupported MIME type"

Comment 10

[Tooru Fujisawa [:arai]]

sounds like the fetch's response MIME-Type is different between your linux environment and your macOS environment,
the latter seems to be "application/wasm", according to the following code (which throws "Response has unsupported MIME type" when it doesn't match "application/wasm"):

  https://searchfox.org/mozilla-central/rev/4fc7bfa931189e0718dd70b4c59885829f1d761e/dom/fetch/FetchUtil.cpp#544-553

I cannot find anywhere that defines MIME type for wasm file in-tree,
so I guess it somehow inherits your OS's MIME type info.

anyway, for now I think you can workaround this issue by using non-WebAssembly.instantiateStreaming way in your code,
which uses response.arrayBuffer+WebAssembly.compile+WebAssembly.instantiate, which apparently doesn't use the fetch response's content-type.

Comment 11

[lukas.lueg]

You are right: Adding `application/wasm    wasm` (the `.wasm` filename-extension used here was chosen by my arbitrarily) to `/etc/mime.types` apparently causes the MIME-lookup to succeed by way of filename-extension and the WASM-module now loads fine.

As it turns out there is no entry for `application/wasm` in the official IANA list at all, so there is actually no way a MIME-type check which adheres to the list could possibly succeed and load the module. My guess is that Chrome just does not care about the MIME-type and Firefox on MacOS succeeds because of MacOS unicorn magic powers.

Comment 12

[lukas.lueg]

Side note: Registering `.wasm` for `application/wasm` seems to be ongoing: https://github.com/WebAssembly/design/issues/1202

Comment 13

[Kershaw Chang [:kershaw]]

It looks like we just need to add {"application/wasm", "wasm"} in this table [1].
But I am not sure if this is a correct approach.

bz, could you comment about this? Thanks.

[1] https://searchfox.org/mozilla-central/rev/465dbfe030dfec7756b9b523029e90d48dd5ecce/uriloader/exthandler/nsExternalHelperAppService.cpp#436

Comment 14

[Boris Zbarsky [:bzbarsky]]

Do we want this in the non-overridable defaultMimeEntries list or in the extraMimeEntries list that can be overridden by various stuff?

If nothing in the world other than WASM has ever used the .wasm extension for anything, adding to .defaultMimeEntries is probably fine.

Comment 15

[Kershaw Chang [:kershaw]]

Attachment: Bug 1500710 - Add default MIME type definition for .wasm as 'application/wasm'

Add {"application/wasm", "wasm"} mapping in extraMimeEntries

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/de93460e55c4
Add default MIME type definition for .wasm as 'application/wasm' r=bzbarsky

Comment 17

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/de93460e55c4