Considerations for WebAssembly runtime

[mingyaulee]

Web development is no longer just dominated by JavaScript with the emergence of more WebAssembly runtime and framework.

There are certain limitations when it comes to using WebAssembly to develop an extension, such as longer load time and bigger package size.

With this in mind, decisions such as deprecating persistent background in favour of service worker needs to be reconsidered because if the extension has a fresh start for every event, we will face similar issue of having "cold start" in serverless applications. I have been using Blazor to develop extensions and generally the pages take about 3 seconds to startup. I haven't been developing more advanced scenarios so that is all I can think of so far.

[dotproto]

#41 touched on a similar request, but I believe it focused more specifically on exposing bindings in Wasm.

On the topic of bindings, as I understand it, projects like Rust have to use tools like wasm-bindgen to create JS bindings that expose DOM and other JS APIs to Rust code. This adds a layer of indirection to Wasm projects that increases the amount of code that browsers must parse, cache, and execute on initial execution, and potentially increases runtime costs. Long term it would be ideal for browsers to expose WebExtension bindings directly to Wasm code, but this is blocked on the Wasm project's interface-types work.

[mingyaulee]

Just to add on to the issue description, after trying to port an extension developed with Blazor to manifest V3, it is not possible to load web assembly because of the restrictive permissions (no wasm-eval, unsafe-eval and sha256 hash permission allowed in V3).

Note: Unsafe eval is required by Chrome to run web assembly right now. WebAssembly/content-security-policy#7

[OluAgunloye]

#41 touched on a similar request, but I believe it focused more specifically on exposing bindings in Wasm.

On the topic of bindings, as I understand it, projects like Rust have to use tools like wasm-bindgen to create JS bindings that expose DOM and other JS APIs to Rust code. This adds a layer of indirection to Wasm projects that increases the amount of code that browsers must parse, cache, and execute on initial execution, and potentially increases runtime costs. Long term it would be ideal for browsers to expose WebExtension bindings directly to Wasm code, but this is blocked on the Wasm project's interface-types work.

No, lol. This is not a problem w/ WASM.

[didyk]

Just to add on to the issue description, after trying to port an extension developed with Blazor to manifest V3, it is not possible to load web assembly because of the restrictive permissions (no wasm-eval, unsafe-eval and sha256 hash permission allowed in V3).

Note: Unsafe eval is required by Chrome to run web assembly right now. WebAssembly/content-security-policy#7

Started to move from manifest v2 to v3 and face this problem too

[Rob--W]

FYI: extensions can now use WebAssembly if they specify 'wasm-unsafe-eval' in their CSP, see #98 (comment). Support for that directive source has landed in Firefox 102 and Chrome 103. More details on support in Firefox and Chromium across browser versions is at https://bugzilla.mozilla.org/show_bug.cgi?id=1766027#c2

[Jack-Works]

Support for that directive source has landed in Firefox 102 and Chrome 103

Also for Manifest V3?

[Rob--W]

Support for that directive source has landed in Firefox 102 and Chrome 103

Also for Manifest V3?

Yes, in Firefox and Chromium. See bugs and comments that I have linked before.

[Rob--W]

While 'wasm-unsafe-eval' allows extensions to use wasm, it is not ideal because it also opens the door to arbitrary wasm code from remote sources.

The browser vendors among us are starting to look for ways to enable extensions to only use wasm bundled with the extension. This discussion starts at: WebAssembly/content-security-policy#37 (comment)