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
