The Ashes

Piers Lawson has come up with an interesting new technique for cross domain communication using an iframe and not having to poll the location for a #hashchange:

Most articles on using the URL Fragment technique advocate the target iFrame polling its Location to detect changes in the fragment… perhaps checking 5 times a second. Julien Lecomte describes a variant that creates throw away proxy iFrame’s. These can check their location within an onload event handler, extract the message, then make a call to the target iFrame, passing in the message. Once complete, the iFrame can be deleted. This means polling is no longer required. Also, when combined with caching, it should be fast and remove the risk of missing a message.

This post by Michael Mahemoff provides a good introduction to both techniques.

I came across these blog entries after I had come up with something similar, but with a slight twist… it may not be new but I didn’t find any other examples along these lines. I used a permanent proxy frame instead of throw away proxies. However, rather than polling the Location, I signalled a new “message” was ready to be processed by resizing the proxy iFrame. The JavaScript within the proxy iFrame registers a resize handler which when triggered reads the message. This approach is more immediate than both the polling and the dynamic iFrame techniques. I’m not 100% sure on whether threading within browser could allow messages to be lost in the case of several being sent close together, but I don’t believe so.

It is interesting to see how it all works:

The Parent Page hosts two iFrames. One contains the Content to be displayed, the second is a Proxy that is moved out of sight (both iFrames are served by the same domain);

The Parent Page sends messages to the Content iFrame by changing the URL Fragment of the Proxy iFrame and signalling that a new message is available (by toggling the size of the Proxy):

PLAIN TEXT

JAVASCRIPT:

1.  
2. function SendMessageToFrame(message) {
3.     var elem = document.getElementById(‘innerFrameProxy’);
4.     elem.contentWindow.location = ‘http://www.pierslawson.plus.com/Examples/CrossDomain/InnerFrameProxy.html#’ + message;
5.     elem.width = elem.width> 50 ? 50 : 100;
6. }
7.  

The Proxy registers a handler that is called as its size is changed. The handler inspects the URL Fragment and passes the message on to the Content iFrame (this is allowed as it is not a cross domain call). It is this call that fails with Opera… there does not appear to be a way for the Proxy iFrame to get a handle to the Content iFrame. Internet Explorer and Firefox can use parent.frames["hostFrame"] to find the Content iFrame.

Nice work Piers!