Iframe Security and the onload event
I do a substantial amount of development with a Comet application, and utilize iframes for communication. Most web developers hear “frames” and their eyes immediately glaze over and they just look at you as if you’re nuts. “No, not FRAMES…IFRAMES!” Iframes are used more than you realize, and, when used correctly, can be very beneficial to the user experience.
When using iframes, you have to be aware of their security model. Any modern browser prevents iframes from interacting with each other unless they are from the same domain. This is in place for obvious reasons, I wouldn’t want an advertising banner hosted in an iframe to access the parent page’s DOM or cookies.
However, there are times when you want to use iframes within your site, but pointed to different subdomains. Perhaps you have a content iframe hosted at data.mydomain.com feeding information to your parent page accessed via www.mydomain.com. The default iframe security model will prevent interaction between them because it is limited to the fully qualified domain name as specified in the src attribute. You can relax this to simply be the primary hostname, in this case mydomain.com. To do so, add a single line of javascript code to the top of your page:
document.domain = 'mydomain.com';
That single line, added to both the parent and iframe source page, will allow them to interact without restriction. Use at your own risk, always be aware of what is happening when your frames are interacting and avoid confusing the user.
In my Comet application, I needed to dynamically add an iframe and then tear it down when it’s processing was complete. I could have left it hanging out in the DOM, but that’s just not clean and efficient programming. After some research, I found this which explained exactly what was going on, and what I needed to do about it:
Thanks and kudos to Nicholas for the great and in-depth article, he addressed cross-browser compatibility and gave a very complete (and workable) solution!