On 20 Mar 2007, at 15:45, Hallvord R M Steen wrote:
1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.
The UA can not do this. It would break legacy pages by resetting
window.opener if content comes from a different server.
If this is a security point, which I take from the subject
"window.opener and security" it is, there is no problem with a UA
breaking an implementation that relied on insecurity.
I can't think of a single reason that when a user navigates to
another domain, you would want that domain to access your
window.opener, so the UA clearly could do this.
I personally think the UA should handle it (as stated previously)
**BUT** if they do not, you *ARE* responsible for programming
correctly and using an unload to null the property when someone
navigates away.
Wouldn't it then be cleaner to be able to tell the UA in advance that
the window should not have an .opener property?
Isn't this about security?
There is no security risk allowing your own window to access .opener.
When you switch domains, the UA either nulls it, or as is the current
case, on WebKit at least, it throws exceptions when you try to access
it.
I don't see the need for this property at all.
**AND** you seem to want this extension to cure a problem, that is
also cured by window.opener.opener
You mean window.top.opener . No, that issue is in no way related to
the suggested extension.
i didn't mean window.top.opener
document.getElementsByTagName('iframe')
[0].contentWindow.opener=self.opener;
