23685 2013-10-30 19:23:45 +0000 postMessage should not be required to throw when attempting to transfer the "target" port 2013-11-21 23:49:07 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED P3 normal Unsorted 1 adamk ian ian jonas mike contributor oldest_to_newest 95572 0 adamk 2013-10-30 19:23:45 +0000 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. 95619 1 adamk 2013-10-31 17:40:23 +0000 A halfway proposal would also allow user agents than can synchronously detect this error condition to throw. 95621 2 ian 2013-10-31 19:15:10 +0000 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. 96342 3 adamk 2013-11-14 19:27:30 +0000 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) 96677 4 contributor 2013-11-21 23:49:07 +0000 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