Well, I don't think it is off-topic.
You are trying to justify writing to a property I think should be
read-only.
I am asking you why you think this should be possible.
Anyway, for use case 1 - If you are worried about phishing attacks,
you should be using some sort of
onunload handler trapping to null window.opener. Then you can be sure
it won't be absued by anyone, even
if the user leaves your site by typing in a new uri.
For case 2, you have an iframe in a popup wanting to communicate with
the opener?
what is wrong with window.opener.opener ?
I personally think that as soon as the domain changes the UA should
null window.opener, but if it doesn't you can work around it as I
said, and I think you have a non-existent problem in case 2.
*back to topic*
I don't think you need this property, you are free to send null to
the child window's opener as things are now, and I would argue for
making the property read-only in any future spec anyway, making the
UA responsible for security.
Gareth
On 20 Mar 2007, at 13:21, Hallvord R M Steen wrote:
On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another
parent?
Again: We are off-topic. This isn't what I'm trying to discuss in
this thread.
However, here are two use cases for you:
1) I don't want the next page to mess with opener:
window.opener=null;
location.href='http://some-untrusted-location/';
(basically what sites should do today to work around the phishing
potential issue, but AFAIK none do.)
2) I have contents in an IFRAME that I want to talk directly to MY
opener:
document.getElementsByTagName('iframe')
[0].contentWindow.opener=self.opener;
What are your "exploit cases" where setting .opener is so dangerous
that it should throw? Note that making it throw also means being
backwards incompatible with
var opener='Once upon a time, ';
which might be far-fetched but certainly will exist somewhere if
browsers haven't thrown exceptions so far.
Now if you have time I'd like some comments on the proposal
window.open(url,name, 'openerproperty=0');
;)
On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:
> On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
>> window.opener should be read-only and attempting to write to it
>> should throw an exception.
>
> I don't really see why setting opener would be dangerous, so I
> disagree that it should throw. Anyway, that is a different
issue. What
> I'm talking about is the built-in behaviour - the browser itself
sets
> window.opener in all popups, and there is currently no way to
open a
> popup that is prevented from changing the location of its opener.
>
> (An exception is Opera applying a stricter security policy if the
> opener is an https page so in this case popup can't set location of
> its opener, but I'm not sure if the other UAs do this.)
>
--
Hallvord R. M. Steen
