W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: connection ceremony for iframe postMessage communications

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 10 Feb 2012 23:56:12 +0000 (UTC)
To: John J Barton <johnjbarton@johnjbarton.com>
cc: public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1202102345420.10315@ps20323.dreamhostps.com>
On Fri, 10 Feb 2012, John J Barton wrote:
> I think there are two more cases. Because the messages are all async,
> the 'it gets missed case" can be "it gets delayed". That causes
> additional messages.
>   - parent opens iframe, then sets up communications, iframe is quicker:
>    -  iframe sends 'load' message when ready, but it gets delayed
>    - parent sends 'ping' message
>    - parent get first 'load' message, responds with port
>    - iframe sends 'load' message in response to 'ping'

Yeah, after receiving the first 'load', the parent should stop listening 
for more 'load's.

>  - parent opens iframe, then sets up communications, parent is quicker:
>    - parent sends 'ping' message, but it gets delayed
>    - iframe sends 'load' message when ready
>    - iframe gets 'ping' message, sends 'load' message in response
>    - parent gets 'load' message, responds with port

That's equivalent to the case of the parent not hooking things up until 
after the iframe is ready.

> This doe not change your conclusion, "the first 'load' message indicates 
> ready", but I believe it does mean that a third message (sending the 
> port) is needed.

Well, probably far more than three messages -- each time you want to start 
a conversation you would send a port for that conversation. (By 
"conversation" I mean an instance of the parent invoking a feature that 
the iframe provides.)

> The 'load' message cannot also send the port.


> > (In practice it's usually much simpler than any of this because the 
> > parent can guarantee that it sets up its communications first, before 
> > the iframe is even created, and the child can guarantee that it sets 
> > up its communications before it finishes loading, so the parent can 
> > just use the regular 'load' event on the iframe and the child never 
> > needs to wait at all if it wants to start communicating first.)
> Entangling communications setup with iframe 'load' just makes a 
> complicated problem harder, not simpler. If we can encapsulate the above 
> logic in a communications library then we don't have to involve the UI 
> or impact performance delaying load.

Whatever works for you.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 10 February 2012 23:56:35 UTC

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