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.
This affects Safari 419.3 as well.
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.
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.
This lacks a test case and I'm pretty sure this is working as intended now as otherwise a whole lot would be amiss.