Frames are unable to set their window.opener property to null.
Webmail sites, such as Gmail, commonly set window.opener to null when following hyperlinks to prevent the destination page from navigating the user away from their webmail session. If the user fails to notice the location bar has changed, they might fall victim to a spoofing attack.
Internet Explorer, Firefox, and Opera all permit sites to set their window.opener property to null.
Steps to reproduce:
1) Send yourself a Gmail message with a hyperlink to
2) Click the hyperlink in Gmail.
3) Click the 'alert(window.opener === null);' button.
4) Click the 'window.opener.location = "http://www.yahoo.com/";' button.
1) Clicking the first button alerts "true".
2) Clicking the second button throws a null pointer exception.
1) Clicking the first button alert "false".
2) Clicking the second button navigates Gmail to http://www.yahoo.com/.
I think this should be straight-forward to fix, but I don't have a patch in hand yet.
WebKit allows frames to set window.opener, just not across domains. The same is true of Firefox. I think the difference in behavior here must have some other cause.
> I think the difference in behavior here must have some other cause.
Yes, you're right. The real issue is that the window.opener property is being reset after navigation, see:
When you follow a link in Gmail, they first call window.open(""), and then document.write content into the open window that nulls the opener and navigates the window to the destination. WebKit is resetting the opener during navigation.
Modified title to reflect Adam's analysis.