User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

I created a new WebAssembly.Memory(…). I also created an object with two Int32Arrays backed by the memory's buffer. Then I posted them to a worker and got different results depending on the order of the memory and the object.

I have uploaded a minimum reproduction to https://github.com/DDR0/Stardust/tree/memory-issue-2-reproduction. main.mjs sends the messages as detailed above, and sim.mjs echos the messages received to the console. I have included example_server.py to serve the files cross-origin-isolated, so shared memory gets enabled.

Actual results:

Console:

🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
⚠ [object MessageEvent] sim.mjs:2:45
🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
⚠ [object MessageEvent]  sim.mjs:2:45

Expected results:

Console:

🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
🛈 Worker Thread: [object WebAssembly.Memory],[object Object]. sim.mjs:1:47
🛈 Worker Thread: [object Object],[object WebAssembly.Memory]. sim.mjs:1:47
🛈 Worker Thread: [object WebAssembly.Memory],[object Object]. sim.mjs:1:47

Note: The above shows up if I back the memory with a normal SharedArrayBuffer(10) or only have one TypedArray in the object. The typed arrays don't have to be in the object.

Note: While Chromium does transfer [memory, object], it transfers [object, memory] as null, firing the worker's message event in both cases. This issue does not reproduce in Firefox, and only needs one typed array instead of two. I have filed it with them at https://bugs.chromium.org/p/chromium/issues/detail?id=1421524.

Thank you!

Im not sure if this is the correct component for this issue, hopefully one of our devs can take a look and move it to a more suitable one.

The sister Chromium issue, mentioned above, has been fixed now.

Ben, could you take a look?