- From: John J Barton <johnjbarton@johnjbarton.com>
- Date: Thu, 9 Feb 2012 21:41:15 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps <public-webapps@w3.org>
On Thu, Feb 9, 2012 at 4:42 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 9 Feb 2012, John J Barton wrote:
>>
>> However the solution has two significant problems:
>> 1. There is no way to know if portToOtherWindow is connected before
>> you issue postMessage()
>
> Just have the target message you when it's ready.
Ah, ok, just to translate (in case anyone understood what I was
talking about before): there already exists an out-of-band
introduction system, the global postMessage(), which can be used to
set up the in-band channel by sending MessageChannel ports as
Transferables.
Let me see if I can understand this.
Both sides create MessageChannel objects;
both sides window.addEventListener('message', handler, false)
both sides issue other.postMessage("...", "*", [channel.port2]);
The second-place finisher in the race succeeds in posting its port2 to
the first-place racer. The first-place racer knows it 'won' because it
gets the port. But how does the second-place racer know it should use
channel.port1 rather than continue waiting? I guess the first-place
racer can send an ACK.
If yes, then this ACK message needs to be standard for cross-domain iframes.
We also need the containing window's global introduction handler to
associate the given port with the correct iframe. The difficulty here
is that no property of event.source is available (similar I suppose to
iframe.contentWindow having nothing but errors to offer beyond only
postMessage). Experimentally
event.source === other
is true in the handler. Is this given by the standard?
>
>
>> 2. All iframes send messages to the same "handler".
>
> Pass a MessagePort to the target when you start a new conversation, and
> do the rest of the conversation on that.
Yes this part is cool.
jjb
Received on Friday, 10 February 2012 05:41:45 UTC