[whatwg] Changing postMessage() to allow sending unentangled ports

[Drew Wilson]

I'm saying that we should differentiate between the "closed" state and
"cloned" state.
Implementors effectively need to do this anyway, because the spec says that
closed ports are still task sources, while cloned ports are not.

It makes sense to be able to post closed ports via postmessage() because
they are still task sources so the recipient could attach an onmessage
handler and pull messages off them.

It makes no sense to re-send an already-cloned port since it's not a task
source and can't ever be a task source again (no way to send messages to
it). Likewise it is no longer entangled and so you can't send messages via
it. Re-sending a cloned port is an error, and we should treat it as such.

-atw

On Fri, Aug 28, 2009 at 12:11 PM, Ian Hickson <ian at hixie.ch> wrote:

> 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
> > again
>
> 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.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090828/9cf6d5fb/attachment-0002.htm>