13062 2007-03-13 18:13:47 -0700 Implement contentWindow for iframes 2007-03-13 22:58:00 -0700 1 1 1 Unclassified WebKit DOM 523.x (Safari 3) PC OS X 10.4 RESOLVED INVALID P2 Normal --- 0 netdragon webkit-unassigned ap jhaygood oldest_to_newest 18836 0 netdragon 2007-03-13 18:13:47 -0700 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. 18837 1 13621 netdragon 2007-03-13 18:17:20 -0700 Created attachment 13621 Frame src for testcase 18839 2 13622 netdragon 2007-03-13 18:26:34 -0700 Created attachment 13622 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/ 18843 3 13624 netdragon 2007-03-13 18:41:33 -0700 Created attachment 13624 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. 18844 4 13624 netdragon 2007-03-13 18:46:21 -0700 Comment on attachment 13624 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. 18845 5 netdragon 2007-03-13 19:04:58 -0700 Now everything's working fine. So weird, but oh well... -> INVALID unless I can make it happen again reproducibly. 13621 2007-03-13 18:17:20 -0700 2007-03-13 18:46:53 -0700 Frame src for testcase inframe.html text/html 161 netdragon PGh0bWw+DQo8Ym9keT4NCjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0IiBsYW5ndWFnZT0i SmF2YXNjcmlwdCI+DQo8IS0tDQoJZG9jdW1lbnQud3JpdGVsbigiZnJhbWUiKTsNCgl2YXIgbXlW YXIgPSAiSGVsbG8iOw0KLS0+DQo8L3NjcmlwdD4NCjwvYm9keT4NCjwvaHRtbD4= 13622 2007-03-13 18:26:34 -0700 2007-03-13 18:41:33 -0700 Here is the testcase. It will work on every major browser but Safari testcase.html text/html 631 netdragon PGh0bWw+DQo8Ym9keT4NCjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0IiBsYW5ndWFnZT0i SmF2YXNjcmlwdCI+DQo8IS0tDQpmdW5jdGlvbiBkaXNwbGF5VmFyKCkNCnsNCglkb2N1bWVudC5n ZXRFbGVtZW50QnlJZCgiZGlzcGxheURpdiIpLmlubmVySFRNTCA9IGRvY3VtZW50LmdldEVsZW1l bnRCeUlkKCJ0ZXN0RnJhbWUiKS5jb250ZW50V2luZG93Lm15VmFyOy8qIEkga25vdyBpbm5lckhU TUwgaXMgImV2aWwiLCBidXQgdGhpcyBpcyBqdXN0IGEgdGVzdGNhc2UgKi8NCn0NCi0tPg0KPC9z Y3JpcHQ+DQpPdXRwdXQgZ29lcyBoZXJlOiA8ZGl2IHN0eWxlPSJ3aWR0aDogODAwcHg7IGhlaWdo dDogNTBweDsgYm9yZGVyOiAxcHggc29saWQgcmVkOyI+PC9kaXY+DQo8YnI+DQo8aW5wdXQgdHlw ZT0iYnV0dG9uIiBvbmNsaWNrPSJkaXNwbGF5VmFyKCkiIHZhbHVlPSJjbGljayBoZXJlIHRvIHNo b3cgaWZyYW1lLmNvbnRlbnRXaW5kb3cubXlWYXIiPjxicj4NCjxpZnJhbWUgc3JjPSJodHRwOi8v YnVncy53ZWJraXQub3JnL2F0dGFjaG1lbnQuY2dpP2lkPTEzNjIxIiBpZD0idGVzdEZyYW1lIiBi b3JkZXI9IjEiIHdpZHRoPSI4MDAiIGhlaWdodD0iNTAiPjwvaWZyYW1lPg0KPC9ib2R5Pg0KPC9o dG1sPg== 13624 2007-03-13 18:41:33 -0700 2007-03-13 18:46:21 -0700 Here is the testcase. It will work on every major browser but Safari testcase.html text/html 647 netdragon PGh0bWw+DQo8Ym9keT4NCjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0IiBsYW5ndWFnZT0i SmF2YXNjcmlwdCI+DQo8IS0tDQpmdW5jdGlvbiBkaXNwbGF5VmFyKCkNCnsNCglkb2N1bWVudC5n ZXRFbGVtZW50QnlJZCgiZGlzcGxheURpdiIpLmlubmVySFRNTCA9IGRvY3VtZW50LmdldEVsZW1l bnRCeUlkKCJ0ZXN0RnJhbWUiKS5jb250ZW50V2luZG93Lm15VmFyOy8qIEkga25vdyBpbm5lckhU TUwgaXMgImV2aWwiLCBidXQgdGhpcyBpcyBqdXN0IGEgdGVzdGNhc2UgKi8NCn0NCi0tPg0KPC9z Y3JpcHQ+DQpPdXRwdXQgZ29lcyBoZXJlOiA8ZGl2IGlkPSJkaXNwbGF5RGl2IiBzdHlsZT0id2lk dGg6IDgwMHB4OyBoZWlnaHQ6IDUwcHg7IGJvcmRlcjogMXB4IHNvbGlkIHJlZDsiPjwvZGl2Pg0K PGJyPg0KPGlucHV0IHR5cGU9ImJ1dHRvbiIgb25jbGljaz0iZGlzcGxheVZhcigpIiB2YWx1ZT0i Y2xpY2sgaGVyZSB0byBzaG93IGlmcmFtZS5jb250ZW50V2luZG93Lm15VmFyIj48YnI+DQo8aWZy YW1lIHNyYz0iaHR0cDovL2J1Z3Mud2Via2l0Lm9yZy9hdHRhY2htZW50LmNnaT9pZD0xMzYyMSIg aWQ9InRlc3RGcmFtZSIgYm9yZGVyPSIxIiB3aWR0aD0iODAwIiBoZWlnaHQ9IjUwIj48L2lmcmFt ZT4NCjwvYm9keT4NCjwvaHRtbD4=