Open Bug 1821582 Opened 2 years ago Updated 5 months ago

`worker.postMessage` with a WebAssembly.Memory followed by 2 typed arrays doesn't work.

Categories

(Core :: JavaScript: WebAssembly, defect, P2)

Firefox 109
defect

Tracking

()

UNCONFIRMED

People

(Reporter: d, Assigned: bvisness)

References

(Blocks 1 open bug)

Details

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.

QA Whiteboard: [qa-not-actionable]
Component: Untriaged → JavaScript: WebAssembly
Product: Firefox → Core

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

Ben, could you take a look?

Assignee: nobody → bvisness
Severity: -- → N/A
Priority: -- → P2
Severity: N/A → S3

I have issue with this site https://bloxfruitsscripts.com/

You need to log in before you can comment on or make changes to this bug.