[whatwg] postMessage() issues

[Ian Hickson]

On Tue, 15 Apr 2008, Sunava Dutta wrote:
>
> Just following up to my email a few weeks back regarding cross document 
> messaging. 
> http://lists.w3.org/Archives/Public/public-html-comments/2008Feb/0024.html
> 
> We'd love to know whether our proposed changes here (in the rewrite) can 
> be accepted or not. Either way, we intend on conforming to the standard 
> and it's important to us to know the decision here. I haven't heard a 
> response from an HTML 5.0 member yet. (Although Jeff Walden from MIT was 
> gracious enough to share his thoughts)

I will deal with this feedback ASAP.


> For your convenience, I've isolated the core of the request.

Thanks, that helps -- I was studying the text you proposed and couldn't 
work out what the new text was!


> "For the postMessage (message, origin) method we would recommend the 
> parameter be called postMessage(message, targetOrigin) since it's easier 
> to understand what it is."

I'll be happy to make that change.


> In addition, as our Beta 1 launch indicates, we're very keen on shipping 
> this feature in IE8. Any indication on potential changes to the draft in 
> this area as soon as possible will help us ship a release that's in 
> harmony with the latest developments.

Thanks for letting me know. I shall prioritise this.


On Tue, 15 Apr 2008, Sunava Dutta wrote:
>
> Looking at the current draft for cross document 
> messaging<http://www.w3.org/html/wg/html5/#crossDocumentMessages>, I was 
> wondering if there is any guidance on the scope for postMessage. 
> Specifically, does the postMessage send data across tab/process 
> boundaries? (If there is guidance here in an updated draft I apologize, 
> can't seem to find it!)

Yes, it is supposed to work cross-tab (and cross-process, if tabs are in 
different processes). Because the postMessage() API is synchronous, this 
also implies that all scripts across all processes that can in any way 
communicate with each other have to be synchronous, so there has to be an 
inter-process lock to keep the scripts from running at the same time 
(otherwise you can get two tabs try to talk to each other at the same time 
and the entire thing would lock).

At the moment people have proposed that the API be asynchronous, and some 
people are ok with that, but other people are strongly opposed to it. I am 
not sure where to go with this. Input from other browser vendors -- 
yourself and WebKit in particular -- would be very useful. Right now the 
API is synchronous, and Mozilla reps have indicated they strongly prefer 
that, Opera reps have indicated they don't mind, and Gears reps have 
indicated they'd rather it be async.


> Here are a few arguments/counter-arguments that come to mind...
> 
> * Against allowing this: Limiting it to the same Tab would make it 
> equivalent to IFRAM hack in IE functionality wise.( 
> http://tagneto.blogspot.com/2006/06/cross-domain-frame-communication-with.html)
> 
> o It would drastically reduce our attack surface without reducing its 
> usefulness too much.
> 
> * For allowing this: Granted it would be even more powerful if we allow 
> postMessage to go across thread/process boundary.  Ensuring this feature 
> is consistent with other DOM reach-ability will be architecturally 
> sound. If a web developer can set window.location on a given target, 
> being able to post a message to it would make sense. I'm excited to hear 
> thoughts here!

Indeed, the idea is that it be similar in access to window.location.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'