[whatwg] Request: window.postMessage should be async

[Aaron Boodman]

On Sun, Apr 6, 2008 at 1:52 AM, Aaron Boodman <aa at google.com> wrote:
>  There doesn't seem to be any advantage to it.

I take it back, there is one advantage, which Jeff brought up:

> > function realMessageHandler(messageEvent) {
> >  // handle the message...
> >  // and, reply to the message
> >  messageEvent.source.postMessage("response message");
> > }
> >
>
>  Furthermore, note that the above behavior is actually *insecure* if the
> handler authenticates the sender and discloses some secret in his response,
> because |messageEvent.source| may have been navigated to a different origin.
> Making the API async basically requires the optional origin argument always
> be provided to postMessage, adding API complexity.  If a piece of
> information doesn't have to be [present] for the system to [usually] work,
> sooner or later it won't be [and the system won't work].[1]

But I think the fact that messageEvent.source can be navigated and
still be the "source" is real issue here. To me, messages sent to
messageEvent.source after it has been unloaded should throw. I realize
this means that it cannot be the same object as is accessible via
window.frames[], but that seems OK to me. Actually, that is exactly
what hixie's messages proposal [1] does in this case.

That would address the only reason I've seen for making this API
synchronous, and it would also eliminate the need for authors to pass
origin when replying to messages received via sendMessage.

- a

1. http://hixie.ch/specs/dom/messages/0.9