[whatwg] Changing postMessage() to allow sending unentangled ports
ian at hixie.ch
Fri Aug 28 12:11:49 PDT 2009
On Mon, 17 Aug 2009, Drew Wilson wrote:
> Following up on this issue:
> Currently, the checks specified for MessagePort.postMessage() are different
> from the checks done in window.postMessage() (as described in section 7.2.4
> "Posting messages with message ports").
> In particular, step 4 of section 7.2.4 says:
> If any of the entries in ports are null, *if any of the entries in
> **ports** are not entangled **MessagePort** objects*, or if any
> MessagePort object is listed in ports more than once, then throw an
> INVALID_STATE_ERR exception.
It appears that this is fixed.
> Also, as written, the spec now incorrectly lets us send a cloned port
> multiple times. So code like this would not generate an error:
> var channel = new MessageChannel();
> otherWindow.postMessage("message1", channel.port1);
> otherWindow.postMessage("message2", channel.port1); // Sent the same port
That's intentional. By the second call, channel.port1 is not entangled;
the 'message2' event will have a lame duck port as its port.
> The current WebKit behavior is to throw an INVALID_STATE_ERR in this
> case, while still allowing closed ports to be sent, which I believe is
> the intended behavior based on previous discussions. If this is correct,
> we should update the spec to prohibit resending cloned ports.
I don't see how this could be correct.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg