[whatwg] Inter-window communication beyond window.postMessage()

[Sidney San Martín]

> On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> 4. Open a SharedWorker and send a MessagePort to the other window.

I'm not too familiar with shared workers, but I read through the spec
and it looks like they suffer from the SOP (as Drew mentioned).
(LocalStorage also suffers from this, I shouldn't have included it in
the original post.)

> How do you know there's a Window to get a hold of if you don't have a hold
> of it already?

You don't. What's common among the use cases for this kind of
inter-window communication is that you are trying to talk to windows
which may have been around longer than you or were created after you.
If the call fails or you get no response, handle it (tell the user,
open the window, or do nothing.).

> The main reason for Window.postMessage() is communication with iframes
> (gadgets), not with other top-level browsing contexts. What's the use case
> for the latter?

On Mon, Sep 14, 2009 at 8:57 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> I assume the use case for this is similar with the use case for storage
> events which essentially is a broadcast mechanism that's specific to just
> DOM storage.  So if, for example, you wanted to tell your other windows
> "hey!  I changed the cookie" then you could do it with a message.  This
> seems much better than, for example polling.
> This could also be useful if you wanted to say "hey, I just navigated to
> gmail.com.  Do any of you already have the inbox and chat contacts loaded
> up?".  I suppose there's not much advantage to doing it like this over
> shared workers since either way you're passing messages, but I also don't
> see any major downsides to allowing broadcasts.

The original case that made me start exploring these APIs was a "stuff
browser" that I'm working on (think address book). The browser stays
open (as a popup) and can be used alone, but other pages should be
able to ask it to navigate to a specific record. A shared worker would
actually work quite nicely in this situation, but wouldn't work at all
across-domains.

For instance, websites are big these days on asking for login
information for webmail clients to pull down contacts. What if an
informal protocol were developed for exchanging contact information?
Then, let's say I'm on Google Voice and want to call a number from my
address book (which may be run by an unrelated company). Google Voice
checks to see if I have a window open that identifies itself as an
address book, sends it a MessagePort, and displays an "add from
address book" button next to the phone number field. When I click the
button, the address book's UI changes to indicate that it's ready for
me to pick a phone number to send back to Google Voice.

The same concept could apply to a password manager. An informal
protocol would let login pages broadcast their existence to other
windows and and if the user happens to have a web-based password
manager open, it could answer the request and send back credentials.

I'm not great at coming up with use cases, but messaging between
separate top-level browsing contexts with different origins isn't
covered by the current APIs, and it's a broad enough category that
more-creative developers will want it once they realize that message
passing exists at all.