A quieter window.name transport for IE
permalinkUsing window.name as a transport for cooperative cross-domain communication is a reasonably well-known and well-researched technique. I came across it via two blog posts by members of the GWT community that were using it to submit GWT FormPanels to endpoints on other domains.
For our product, I’ve been looking at various ways we can offer RPC for our script when it is embedded in pages that don’t run on servers under our control. Modern browsers, like Firefox 3.5 and Safari 4.0 support XMLHttpRequest Level 2. This standard allows you to make cross-domain calls, as long as the server responds with the appropriate Access-Control header. Internet Explorer 8 supports a proprietary XDomainRequest that offers similar support.
When we’re looking at “downlevel” browsers, like Firefox 2/3, Safari 2/3 and IE 6/7, the picture isn’t as clear. The window.name transport works well in every downlevel browser but IE6 and 7. In those IE versions, each RPC request made across the iframe is accompanied by an annoying click sound. As you can imagine, a page that has a few RPC requests that it requires to load will end up sounding like a machine gun. The reason for this is IE’s navigation sound which plays on every location change for any window, including iframes. The window.name transport requires a POST and a redirect back to complete the communication, triggering this audio UI.
I spent a few hours hammering away on the problem, trying to find a solution. It turns out that IE6 can be fooled with a
The interesting thing about the htmlfile ActiveX object is that not all HTML works as you’d expect it to. My first attempt was to use the htmlfile object, creating an iframe element with it, attaching it to the body (along with an accompanying form inside the htmlfile document) and POSTing the data. Unfortunately, I couldn’t get any of the events to register. The POST was happening, but none of the iframe’s onload events were firing:
if ("ActiveXObject" in window) {
var doc = new ActiveXObject("htmlfile");
doc.open();
doc.write("<html><body></body></html>");
doc.close();
} else {
var doc = document;
}
var iframe = doc.createElement('iframe');
doc.body.appendChild(iframe);
iframe.onload = ...
iframe.onreadystatechange = ...
The second attempt was more fruitful. I tried writing the iframe out as part of the document, getting the iframe from the htmlfile and adding event handlers to this object. Success! I managed to capture the onload event, read back the window.name value and, best of all, the browser did this silently:
if ("ActiveXObject" in window) {
var doc = new ActiveXObject("htmlfile");
doc.open();
doc.write("<html><body><iframe id='iframe'></iframe></body></html>");
doc.close();
var iframe = doc.getElementById('iframe');
} else {
var doc = document;
var iframe = doc.createElement('iframe');
doc.body.appendChild(iframe);
}
iframe.onload = ...
iframe.onreadystatechange = ...
I’m currently working on cleaning up the ugly proof-of-concept code to integrate as a transport in the Thrift-GWT RPC library I’m working on. This will allow us to transparently switch to the cross-domain transport when running offsite, without any visible side-effects to the user.
Read full post