Bug 13062 – Implement contentWindow for iframes

• Component: DOM
• Status: RESOLVED INVALID

[Brian Bober]

There is no way to access contentWindow for iframes. That means when attempting to do sites with dynamically loading content inside of iframes, the main page has no way to access variables within the child frame's window, and has to instead have all variables stored on the main window (the parent of the frames). This causes a problem when some content inside the frames are 3rd party (such as floating rich media content).

What should work:
document.getElementById("iframename").contentWindow.myVar

The only way to access an iframe instead:
document.getElementById("iframename").contentDocument

I attempted playing around with contentDocument.defaultView to no avail.

This issue will lead to millions in lost potential revenue for publishing sites who use Ajax. If you want more details on why, I'd be happy to explain if you email me, but it's probably off-topic to discuss here.

[Brian Bober]

Created attachment 13621 [details]
Frame src for testcase

[Brian Bober]

Created attachment 13622 [details]
Here is the testcase. It will work on every major browser but Safari

Every major browser supports contentWindow except Safari (and older versions of Opera). A usage case where this is needed is for a particular major publisher's "ajax" dynamic serving mechanism (where one way to implement it is through iframes), to support rich media expandable content.

Other examples of discussion about this deficiency is here: http://xkr.us/articles/dom/iframe-document/

[Brian Bober]

Created attachment 13624 [details]
Here is the testcase. It will work on every major browser but Safari

Previous testcase had a bug. Note that because the iframe is on the same domain, there's no security restrictions. Some publishers utilize that capability for dynamic load functionality when loading 3rd party content through 3rd party scripts. The difficulty comes in when the iframes need to share variables with the main page.

An example case of when this is needed: A publisher, we'll call MajorPublisherA requested we support their implementation of Ajax ad serving. Their method works by refreshing the src of the serving iframe (iframe A). MajorPublisherA wants us, the rich media vendor, to support all major browsers. As a standard practice, expandable advertisements break out of the ad serving iframe and may create their own container on the main page, hovering over the serving frame, so they can change size on user interaction. However, when the src of the serving frame changes, the next ad will show up, but a remnant of the previous ad will still be there. In a situation like this, we have a "hook" variable on the window of the serving frame, and when we detect that we cannot access that "hook" variable anymore, we know our ad's code has been rotated out, and clean up our expandable advertisement. However, on Safari, as it stands right now, without the contentWindow, we can't detect that the initial serving iframe's src has been changed, and can't therefore clean up the advertisement. I believe I've found a solution so that Safari users will get the same user experience on MajorPublisherA, but it required a massive workaround for something that should be simple, since it's supported on all other browsers.

Another thing all other browsers support is that you can compare window elements inside iframes to the contentWindow of another element to see if they match, even with domain security restrictions. You can't do anything else, but you can compare the two variables. Please make sure when this is implemented, it's implemented in a way that allows the capability of comparing contentWindow and window elements across domains.

[Brian Bober]

Comment on attachment 13624 [details]
Here is the testcase. It will work on every major browser but Safari

This testcase wasn't adequate in reproducing the issue. I'll create a better one in the future.

[Brian Bober]

Now everything's working fine. So weird, but oh well... -> INVALID unless I can make it happen again reproducibly.