Improved for non-awesome browsers by using iframes for communication instead of url fragments and polling. This technique eliminates race conditions where messages sent in rapid succession might not be received. It also removes the need for polling.
Supports almost any conceivable browser, tested with IE6+
Usage
Polyfill setup
To support IE6-7 (and IE8-10 for non-frame windows), you need to make the polyfill HTML file (postmessage.htm) available on your web server.
For example, you could put the file here:
IMPORTANT: This file must be on the same domain as the content you want to communicate with. It cannot be hosted on a different domain (i.e. Google CDN).
Once the file is available, you need to configure the postMessage plugin to point to it. Add this line anywhere on your page (or as the first/last line of jquery.postMessage.js):
Sending a message to another window
$.postMessage() has the following signature:
Note that the $.postMessage() API is slightly different from the HTML5 standard window.postMessage(),
in that it requires explicitly specifying the domain of the target window. This is necessary because there’s
no way to determine the target window’s domain programatically, and the domain is required for the
polyfill technique to work.
Example usage:
Listening to messages from another window
To listen for messages from another window, use jQuery’s built in event handling infrastructure and listen for “message” events on the window object:
This example simply alerts every message it receives, from any origin:
In general, its a good idea to filter out requests from unknown domains. This example filters messages not from http://www.foo.com:
This example alerts every message it receives, from any subdomain of foo.com:
Its also a common practice to “namespace” messages so your handlers don’t respond to messages they don’t know how to handle: