Unable to import WebAssembly modules bigger than 4KB

[kiurchv]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

When importing WebAssembly modules bigger than 4KB browser throws

RangeError: WebAssembly.Instance is disallowed on the main thread, if the buffer size is larger than 4KB. Use WebAssembly.instantiate.

If the current behavior is a bug, please provide the steps to reproduce.

Import the WASM module bigger than 4KB.

What is the expected behavior?

The module should be imported and instantiated correctly.

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

Browser: Google Chrome 64.0.3282.140 (Official Build) (64-bit)
Node.js: 8.9.1
webpack: 4.0.0-beta.1
Operating System: macOS 10.13

[sokra]

@bmeurer Who can I beg to remove this error from Chrome? (only from WASM.Instance, not from WASM.Module)

see also #6433

[bmeurer]

Redirecting to @mstarzinger from the WebAssembly team.

[TheLarkInn]

@kiurchv do you get this error on Microsoft Edge 16-17(insider)? If so I'll also want to see our Chakra team and platform team fall in line here given the tagged issues discussion.

[mathiasbynens]

We have no plans of removing the size limit from Chrome. Using WebAssembly.{Instance,Module} is a bad practice, and hurts the user experience especially for large modules. Use the WebAssembly.instantiateStreaming pattern instead.

[jdalton]

@mathiasbynens Imposing arbitrary limits on APIs is a bad practice. Super disappointed in Chrome's direction on this. It's fine to encourage async use but to offer a sync API and then make it broken is super wonky. As discussed in #6433 there are other ways to discourage API without delivering a broken one.

@sokra From the #6433 (comment) it looks like there's not supposed to be a 4kB limit in workers. Have you found that to be the case and is that something currently being leveraged by webpack?

Update:

It looks like Chrome 66, due out in a few days, will remove the 4kB limit in workers.

[mathiasbynens]

It looks like Chrome 66, due out in a few days, will remove the 4kB limit in workers.

The 4 KB limit never applied in workers, only on the main thread.

[jdalton]

The 4 KB limit never applied in workers, only on the main thread.

Yap, @gahaas corrected the note.

[jasondavies]

Looks like this is still an issue on Chrome Version 66.0.3359.117 (Official Build) (64-bit) macOS 10.13.4?

[gahaas]

@jasondavies did you try it on a worker or on the main thread? If you did it on a worker could you please give me a repro? new WebAssembly.Module() works for me without limitations on a worker.

[jasondavies]

Main thread.

[jasondavies]

BTW, after reading through the other issues (and it appears I misread the comments above), I realise that the 4KB limit still applies on the main thread on Chrome 66, and there are likely no plans to change this. In other words, sorry for the noise!

It seems like switching to instantiateStreaming would close this issue.

[moritzuehling]

Is there a known workaround for this? At the moment it seems like this pretty much renders webpack + wasm unusable. What does the timeline for a fix look like?

[Eruant]

Looks like there are alternatives now:
https://developers.google.com/web/updates/2018/04/loading-wasm

[xtuc]

yes @Eruant Webpack is going to use instantiateStreaming in the future to bypass this limitation.

[sokra]

fixed

[fschutt]

@mathiasbynens Just a note, but instantiateStreaming only works when the response carries the MIME type of application/wasm, which, depending on the hoster of the WASM file, isn't always the case. For example, GitHub servers have no way of setting the MIME type. In such cases, you have to either use the fetch() version or the synchronous version. So please don't "force" people to use the instantiateStreaming API because there might be valid reasons for not using it.

[xtuc]

@fschutt we're adding a fallback here #7983

[mathiasbynens]

@fschutt Yeah, our guidance includes that note: https://developers.google.com/web/updates/2018/04/loading-wasm (look for "Note: The server must be configured to serve [...]")

[jolestar]

Create a URL object by Buffer, then use instantiateStreaming async method to load wasm.

const blob = new Blob([buffer], { type: "application/wasm" });
const url = URL.createObjectURL(blob);
wasm = await instantiateStreaming(fetch(url), {});

https://stackoverflow.com/a/55813693/334103

[Pauan]

@jolestar Don't forget to call URL.revokeObjectURL afterwards:

const blob = new Blob([buffer], { type: "application/wasm" });
const url = URL.createObjectURL(blob);
wasm = await instantiateStreaming(fetch(url), {});
URL.revokeObjectURL(url);