[Webkit-unassigned] [Bug 220038] Unable to postMessage a WebAssembly module to a worklet

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220038

--- Comment #17 from Yusuke Suzuki <ysuzuki at apple.com> ---
Comment on attachment 418682
  --> https://bugs.webkit.org/attachment.cgi?id=418682
WIP Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=418682&action=review

> LayoutTests/imported/w3c/web-platform-tests/wasm/serialization/module/window-messagechannel-success-expected.txt:2
> +PASS postMessaging to a dedicated worker via MessageChannel allows them to instantiate

Can we have a test case that is posting wasm module to message-ports tied to the different process and getting an error in deserialization side?
Ideally, we should throw an error, and we should report onmessageerror since we failed deserialization.
Maybe, we should add a test for checking that error, and after that, we should file a bug for `onmessageerror` handler invocation and implement it.
https://developer.mozilla.org/en-US/docs/Web/API/Worker/onmessageerror
https://developer.mozilla.org/en-US/docs/Web/API/MessagePort/onmessageerror

>> Source/WebCore/dom/MessagePort.cpp:141
>> +    // FIXME: At the time of serialization, we don't know if the target is a window, a worker or something else. We will only know at the time of
> 
> @Yusuke: Not sure how to best deal with this. Passing SerializationContext::WorkerPostMessage unconditionally here is a hack.

This hack looks OK to me! If we attempt to deserialize non-sharable-between-processes objects, then we will get an error at deserialization (not causing catastrophic crash) since our SerializedScriptValue's deserialization is robust enough against that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210201/1627aa64/attachment.htm>