RESOLVED INVALID 8036
parent != iframes[i].contentWindow 
https://bugs.webkit.org/show_bug.cgi?id=8036
Summary parent != iframes[i].contentWindow
Justin Haygood
Reported 2006-03-28 11:42:58 PST
Firefox, Internet Explorer, and Opera let the following check pass, even if you're on a different frame: parent == iframes[i].contentWindow They don't let you access it, but you can tell if they are in fact the same. If you have a Publisher Side File on the domain the original iframe is hosted in, you can 'break out' of the containing frame using this method: * Webpage writes out iframe on different domain (normally an ad server) * iframe writes out iframe pointing to a publisher side file on the original server * new iframe finds the original iframe using the above comparison (reliable, but doesn't work on Safari), using source comparison (not reliable, since iframes can redirect), or size comparison (not reliable, since sites get placement sizes wrong) This breaks compatibility with most portal sites.
Attachments
Add attachment proposed patch, testcase, etc.
Steven Tamm
Comment 1 2006-10-07 10:12:05 PDT
This affects Safari 419.3 as well.
Sulka Haro
Comment 2 2009-12-07 10:41:20 PST
Safari also disallows _session_ cookies inside iframes with the default setting (of only accepting cookies from sites one navigates to), which breaks a number of Facebook applications. I'd understand if the setting disabled persistent cookies, but not accepting session cookies is just beyond my understanding.
Adam Barth
Comment 3 2009-12-07 12:18:36 PST
The cookie issue has nothing to do with the identity of the window object. If you like, you can file another bug. Honestly, though, cookie blocking is done by Safari, not by WebKit. You need to file a bug report with Apple, not the WebKit project.
Anne van Kesteren
Comment 4 2023-05-28 06:45:29 PDT
This lacks a test case and I'm pretty sure this is working as intended now as otherwise a whole lot would be amiss.
Note You need to log in before you can comment on or make changes to this bug.