W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: postMessage is the new wtf

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 13 Dec 2011 15:27:40 -0500
Message-ID: <CABirCh8TM+2YGuekqBiS_OnAaejRdQYaHriOHorp5bJdRV+W0Q@mail.gmail.com>
To: Rick Waldron <waldron.rick@gmail.com>
Cc: Webapps WG <public-webapps@w3.org>
On Tue, Dec 13, 2011 at 11:24 AM, Rick Waldron <waldron.rick@gmail.com>wrote:

>  I'm unable to find documentation or discussion that would clarify the
> rationale of over-using and over-loading the "postMessage" Identifier;

It's not strange that there are differences between methods on completely
different objects; it's not something that needs special explanation.
Using different names for very similar operations would be inconsistent, as
these do the same thing: post a message.  The primary difference is an
added security mechanism for the cross-document messaging that
window.postMessage can perform.

Currently, passing a second arg to worker.postMessage(), that is not a
> MessagePortArray raises
> "Uncaught TypeError: MessagePortArray argument must contain only
> MessagePorts" in Chrome and "Could not get domain" warning in Firefox.

This is a very new feature, and isn't yet available in production
browsers.  Try http://tools.google.com/dlpage/chromesxs, which does have
this.  (As that's a development build, it may not yet be working
completely, of course.)

On Tue, Dec 13, 2011 at 2:11 PM, Dmitry Lomov <dslomov@chromium.org> wrote:
>> window.webkitPostMessage(msg, transferables) does not really exist (it is
>> an error in the blog post, and I am told the post will be amended). What
>> exists is window.webkitPostMessage(msg, targetOrigin, transferables).
> This supports the subject line "postMessage is the new wtf"

The subject isn't very productive approach to asking questions.

This API, and the differences between window.postMessage and
port.postMessage, is well-documented in Web Messaging.

> The spec mandates 'void postMessage(any message, optional
>> sequence<Transferable> transfer)'. Transferable includes both MessagePorts
>> and ArrayBuffers, so in the new spec the transfer argument to postMessage
>> may be a mix of both types, and a backwards-compat extension to what we had
>> before (sequence<MessagePort> aka MessagePortArray). Note that message
>> ports got an additional change in semantics, and can now be mentioned in
>> the message as well - both
>    worker.postMessage({p:port}, [port])
>> and
>>    worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
>> work. Therefore this extension to postMessage semantics is both
>> backwards-compatible and consistent.
> Can you provide a reference for this? I'm unable to locate anything that
> covers these semantics.

Please see the definition of postMessage, which transfers objects (search
for the text "transferring the object x"), and the text: "To transfer a
MessagePort object old to a new owner owner, ...", which defines what
transferring does in the case of MessagePort.

Glenn Maynard
Received on Tuesday, 13 December 2011 20:28:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC