I have a window containing an iframe, containing an iframe, like so:
+---------------+
| Top |
| +-----------+ |
| | Middle | |
| | +-------+ | |
| | | Inner | | |
| | +-------+ | |
| +-----------+ |
+---------------+
Top and Middle are on the same domain, but Inner is on a different domain. I need Inner to communicate with Top. The only way I know of to do this which is supported in IE7 (which I need to support) is to change the hash of the window's location. However, I don't want the information to be flickering in the location bar, so I've introduced the Middle iframe.
I want Inner to change Middle's hash. Middle will read its hash and inform Top, whom it has permission to speak to directly.
However, in Firefox 3, I've been unable to write to Middle's hash from Inner. No error is raised, but the hash appears unchanged. Writing to its location.href
raises a permissions error.
Top can write to Middle's hash, however, and Middle can write to Inner's hash, and Top can write to Inner's hash, and Inner and Middle can both write to Top's hash, so the only ordered pair that doesn't work is the one I want! (I've been working on this for a while.)
I've reproduced this in a minimal test case. At first, I served all three pages from the same domain. When I put Inner on a different domain, I get the problematic behavior. When I put Middle on the second domain, everyone can write to everyone again.
Why can't Inner write to Middle's hash?
Addendum: Many people have suggested that this shouldn't be possible because of the same-origin policy. This is exactly the policy I am trying to get around. This exact case--setting (but not reading) another window's location--is supposed to be possible across domains. I haven't found browser documentation to this effect, but I have found many articles and demos. This is essentially the precursor to HTML 5's postMessage()
.
Ref: http://softwareas.com/cross-domain-communication-with-iframes
Parent frames can set children's iframe 'src' attribute (here with jquery) using:
$("#iframeWindow").attr('src', "http://<CHILD URL>/#hello");
Children iframes can set parent window's href (address bar content) using:
window.top.location.href = "http://<PARENT URL>/#hello"
and in the parent and/or child, you need to poll for changes,
var last = "";
setInterval(function() {
if(last == window.location.href) return;
last = window.location.href;
//do stuff with 'window.location.hash'
}, 1000);
note, it would be nice if you could
window.top.location.href = window.top.location.href + "#hello"
but reading of location object (href and hash) is not allowed
tested on 3rd Nov 11, on chrome, ie6/7/9, firefox 3.6/4
edit1: can put a demo live if people would like
edit2: http://dl.dropboxusercontent.com/u/14376395/html/xdomain.html :)
edit3: beware: if you're using this method, make sure you have control over all iframe'd pages otherwise nefarious 3rd party sites could potentially control yours using hash tags
edit4: better solution http://ternarylabs.com/2011/03/27/secure-cross-domain-iframe-communication/ currently being used by the Google JavaScript API
edit5: dropbox domain name changed to 'dl.dropboxusercontent.com'
To be able to set the location.hash you must first get the location. The same origin policy forbids you from getting the location.
Sounds like this is a bug in Firefox, filed in Bugzilla, according to EricLaw.
Are all the frames containing locations with the same origin? (eg. same protocol, same domain, same port). If they're not it's a potential security vulnerability if one frame can modify the other -- google the same origin policy. But without more details it's difficult to provide a better answer.
I can't answer the why bit for the hash, but have you seen John Resig's work with postMessage
? You're having trouble with FF3, FF3 happens to be one of the browsers that support postMessage
, bingo :-)
Failing that, there's the xssinterface library. Seems to be stable, but I haven't personally tried it.
As Alex said it is a security issue. You can't access Top layer if Inner is on a different domain. This is made to avoid Cross-site Scripting.