User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

1. Unzip the project, call yarn / npm install
2. Start the server with node server.js
3. Go to localhost:8081 and open developer console
4. Click on the "Click me" button

Actual results:

In the console, we see a "ERROR!!: DataCloneError: The object could not be cloned." error when performing a postMessge() of a Webassembly.Module type over the message channel

Expected results:

We should be able to get the Webassembly.Module object on the other end of the message channel.

IIRC, this is simply Not-Yet-Implemented, but we intend to.

Lars/Andrea: do we already have a bug on this? Looks like people actually hitting this so may finally be time to get this fixed.

Steve, can you take a look? I think this is handled by the JS engine, correct?
Do you think is there anything we have to do in DOM-side of the structured clone algorithm?

Actually, the wasm serialization is done in the DOM-world. MessagePort doesn't support wasm because it uses 'DifferenProcess' flag in here:
https://searchfox.org/mozilla-central/rev/f372470e10c8cb0691681603a1d6324dee5b3b8a/dom/base/nsFrameMessageManager.cpp#813

And because of this, WASM modules are not written/read by StructureCloneHolder:
https://searchfox.org/mozilla-central/rev/f372470e10c8cb0691681603a1d6324dee5b3b8a/dom/base/StructuredCloneHolder.cpp#992

So far, we support the cloning of WASM modules only when the cloning happens on the same process, in the same thread: we take a ref of the wasm object and, because of this, we can not use it on a different process. MessagePort uses different-process flag because all the data is sent to the parent process, and from there, it's sent to the destination, which could be on a different process (rarely, basically impossible, I would say).

Now, a couple of questions:

• Are wasm module thread-safe? (useful for cross-thread cloning)
• Can they be serialized, somehow? (useful for different-process cloning)

IIRC, b/c of the explicit intention of the wasm standards group not to have to support cross-process structured serialization of a wasm module, a MessagePort send of a wasm module is supposed to fail if the destination is in a different "agent cluster", which is, iirc, the same rule for SAB. Is that right Lars?

That's right -- a cluster is always same-process and we can in principle post a Wasm memory (if its buffer is a SAB) and a Wasm module to another worker in the same cluster; modules are thread-safe for sure.

For plain postMessage on a Window or Worker object this is not a problem (and posting a Memory or a Module work correctly in this manner already), but for a MessageChannel I believe there is a wrinkle in that a channel is itself a first-class object that is not limited to being transmitted within the agent cluster. Thus if one posts a cluster-limited object on such a channel C without it being retrieved from C immediately, and then posts the channel object C on another channel D so that C escapes the cluster, then we have to be very careful both if objects are taken from C outside the cluster (retrieval should fail), or if C later comes back into the cluster (retrieval should then work as if C never escaped). We have some bugs open on this, but I'm not really sure where they are; I think Anne is the keeper of the secrets here, cc'ing.

Canonical documentation here: http://webassembly.github.io/spec/js-api/index.html. It is silent on structured cloning.

That's bug 1360190, for SharedArrayBuffer. And this would require similar infrastructure for the scenario lth describes, so let's make this depend on that. (It'd be great to get these fixed by the way.)

Canonical documentation for this is at https://webassembly.github.io/spec/web-api/#serialization by the way, which describes serialization quite clearly. (I think it's separate from the JavaScript API because host environments might vary on this in principle.)