WebAssembly.Memory cannot be cloned in this context
-
We're looking into it. This is likely a consequence of changes we're making to reenable shared memory in JS and Wasm in Firefox. These changes will require sites that want to use shared memory to opt into a sandbox mechanism (there's an evolving cross-browser spec for this) so as to avoid Spectre-type side channel attacks.
Specifically, to allow modules containing shared memory to be cloned with postMessage, the server needs to serve the content over HTTPS, and I had to add the following to my http server config file:
<Directory /var/www/sandbox/raytrace> Header set Cross-Origin-Opener-Policy same-origin Header set Cross-Origin-Embedder-Policy require-corp </Directory>(That's probably overly broad but it should be OK) and in Firefox you must enable two prefs in about:config:
javascript.options.shared_memory dom.postMessage.sharedArrayBuffer.withCOOP_COEPVery gory details about the changes to the HTTP spec here: https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k
-
Thanks. According to this: https://bugzilla.mozilla.org/show_bug.cgi?id=1586217 these changes are more on DevOps side (server maintenance) than actual coding. Anyhow, QT WASM documentation should be updated to define this issue.
I try to make the requested changes from the above link to see whether that solves the issue. I will report back with the results.
-
@nagyimre said in WebAssembly.Memory cannot be cloned in this context:
@lorn-potter It does happen with https://www.qt.io/web-assembly-example-mandelbrot
I have talked with FF developers and they said that they introduced some internal strict limits of what object could be cloned. They also stated that they are not talking with Qt devs. I have opened a bug report on Mozilla side: https://bugzilla.mozilla.org/show_bug.cgi?id=1586217
Thank you!
-
I guess this means not being able to use emrun, as I do not think it handles https
-
@lorn-potter In nutshell, if you did not read Mozilla bug: it requires HTTPS and 2 header modifications in the HTTP response header. (we are running our QT WASM application in FF Nightly again)
I think you are right and emrun is out of scope for this. If I have time I do make up a documentation (at least for apache) so you could include into 5.14 delivery.
-
We're trying to implement a workaround for FF Nightly and DevEd to ease developer pain: https://bugzilla.mozilla.org/show_bug.cgi?id=1587394.
-
In Firefox Nightly or Developer Edition only, it should now be possible to set the preference "dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled" to "true" in about:config to allow development in simpler environments (ie the headers will not be required). Going forward, deployment to Beta and Release browsers will still require the headers and HTTPS. Do let us know if development remains difficult.
-
@nagyimre You don't know what I've read, so don't assume you do. I know all about the bug you posted. I was probably the first Qt developer to experience it. The Qt WebAssembly wiki even mentions this bug, which we put there so developers would see it. https://wiki.qt.io/Qt_for_WebAssembly
I just assumed you were testing with emrun.
