[whatwg] using postMessage() to send to a newly-created window

[Darin Fisher]

It sounds tempting to say that the postMessage should be queued until the
newly opened window is loaded, but what point in time is that exactly?  Is
that after the load event is dispatched on the newly opened window?

Note: a newly opened window can begin communicating with its opener much
earlier (via inline script execution).

However, if we try to dispatch the postMessage events before the load event
then the newly opened window may not have registered its event handlers yet.
 (A future <script> tag may define the event handler.)  So, I think we would
have to delay until the load event for the semantics to be sane.

There is perhaps a more critical issue that we should consider.  What
happens if the named window already exists?

Consider this case:

window.open("http://a/", "foo");
...
var w = window.open("http://b/", "foo");
w.postMessage("bar", "*");

I suspect the postMessage would be dispatched in this case, but the event
dispatch would probably go to the document at http://a/ instead of http://b/.
 This is because the browser has no way of knowing if http://b/ will
actually be displayable content.  It could be of a mime type that should
just be downloaded (in which case the indicated window is not navigated).

So, queuing is probably not a good idea.  Workers do not have this issue
since they cannot be "navigated" like a window.

-Darin


On Tue, Jan 5, 2010 at 8:29 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> I understand the rationale, and the workaround you suggest does work,
> (I have tested it, in FF, Safari and Chrome). But, as Jonas mentioned,
> this isn't what we do with workers, and it feels counter-intuitive to
> me (I'm having trouble thinking of other async messaging models that
> require an application-level handshake like this before messaging can
> commence). Are there reasons other than implementation complexity (an
> okay reason) or backwards-compatibility (a better reason) not to have
> the post work in this case? Put differently, would anything break
> (other than a rather oddly written app that explicitly counted on this
> behavior) if this did work?
>
> As an alternative, would it be possible to create an onChildLoad()
> event in the parent so that the parent could reliably send a message
> without needing the child's cooperation? These seems only marginally
> better than having the child post to the parent, so it may not be
> worth it ...
>
> -- Dirk
>
> On Tue, Jan 5, 2010 at 5:00 PM, Darin Fisher <darin at chromium.org> wrote:
> > The window doesn't open synchronously, so you should have to wait for
> > http://x/ to load (or for its document to at least be created) before
> you
> > can start communicating with it.
> > Note: If you instead open "about:blank" you should be able to communicate
> > with it synchronously since "about:blank" is loaded synchronously.  It is
> > special-cased.
> > From the newly opened window, you could try posting a message to its
> opener.
> >  The opener could then handle that event and use it as a signal to know
> that
> > it can know begin communicating with the newly opened window.
> > I haven't tested any of this ;-)
> > -Darin
> >
> > On Mon, Dec 21, 2009 at 7:24 PM, Dirk Pranke <dpranke at chromium.org>
> wrote:
> >>
> >> Hi all,
> >>
> >> In the course of testing something today, I attempted to create a
> >> window and immediately post a message to it, and was surprised that it
> >> didn't seem to work.
> >>
> >> E.g.:
> >>
> >> var w = window.open("http://x");
> >> w.postMessage("hello, world", "*");
> >>
> >> w never got the message - this seemed to be consistent across Safari,
> >> Chrome, and FF (all I had installed on my Mac at the time, so
> >> apologies to Opera, IE, and anyone else I've left out).
> >>
> >> Is this supposed to work? If not, is there a reliable way for the the
> >> source to know when it is safe to send a message to the target? The
> >> only way I can think of is for the target to send a message back to
> >> the source, which only works if the target can get a reference to the
> >> source using window.opener, which may or may not be possible or
> >> desirable ...
> >>
> >> If this isn't supposed to work, can we state this explicitly in the
> spec?
> >>
> >> -- dirk
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100105/c7e02fe2/attachment-0002.htm>