This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23685 - postMessage should not be required to throw when attempting to transfer the "target" port
Summary: postMessage should not be required to throw when attempting to transfer the "...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-30 19:23 UTC by Adam Klein
Modified: 2013-11-21 23:49 UTC (History)
3 users (show)

See Also:

Attachments

Description Adam Klein 2013-10-30 19:23:45 UTC 
In Step 4.2 of http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#dom-messageport-postmessage, user agents are required to throw a DataCloneError if the "target" port (that which will receive this message) is passed in the transfer argument. This is a well-meaning requirement, since there's no way to make sense of such a postMessage call, but in multi-process, multi-threaded user agents it can be difficult-to-impossible to determine what is at the remote end of a MessagePort. See https://code.google.com/p/chromium/issues/detail?id=312962, which includes a test case that fails to throw on both Chrome and Safari.

An alternative would be to remove the throwing requirement and replace it with an async requirement to abort the process and optionally log a console message.
Comment 1 Adam Klein 2013-10-31 17:40:23 UTC 
A halfway proposal would also allow user agents than can synchronously detect this error condition to throw.
Comment 2 Ian 'Hixie' Hickson 2013-10-31 19:15:10 UTC 
I think we want it to be consistent for all cases. So, no throwing, but throw a console message once you realise it's a lost cause.

Maybe once we add a way to detect that the other side has died unexpectedly, we can make this be one of those cases, too.
Comment 3 Adam Klein 2013-11-14 19:27:30 UTC 
Blink has stopped throwing in this case as of http://src.chromium.org/viewvc/blink?view=revision&revision=161083

(cc Jonas so he can route appropriately at Mozilla, I believe they're currently working on implementing MessagePort transferring)
Comment 4 contributor 2013-11-21 23:49:07 UTC 
Checked in as WHATWG revision r8306.
Check-in comment: People apparently don't like it when the spec requires things that are impossible to implement, go figure. (In this case, synchronously detecting that one of the MessagePorts being Transferred in the MessagePort message is actually the target of the message. You can't necessarily know this synchronously, since if the port has been shunted around between workers, you might only discover who the final target actually is after the message has itself bounced between threads for a while.)
http://html5.org/tools/web-apps-tracker?from=8305&to=8306