W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

From: Simon Pieters <simonp@opera.com>
Date: Thu, 14 Jun 2012 09:59:21 +0200
To: "Charlie Reis" <creis@chromium.org>, "Michal Zalewski" <lcamtuf@coredump.cx>
Message-ID: <op.wfvu47r5idj3kv@simons-macbook-pro.local>
Cc: whatwg@whatwg.org, Glenn Maynard <glenn@zewt.org>, Bjartur Thorlacius <svartman95@gmail.com>, Adam Barth <w3c@adambarth.com>
On Thu, 14 Jun 2012 01:44:12 +0200, Michal Zalewski <lcamtuf@coredump.cx>  

>> Any feedback on this revised approach?
> My vague concern is that the separation is a bit fuzzy, beyond saying
> that window.opener will be null... if that's the only guaranteed
> outcome, then maybe that should be spelled out more clearly?

rel=noreferrer already has this feature, FWIW.


"This keyword also causes the opener attribute to remain null if the  
hyperlink creates a new browsing context."

> The
> degree of separation between browsing contexts is intuitive in the
> case of Chrome, given the underlying implementations, but will it be
> the same for Internet Explorer or Firefox or Safari?
> Let's assume that there is no Chrome-style process isolation, and that
> this is only implemented as not giving the target=_unrelated document
> the ability to traverse window.opener. If the document's opener lives
> in an already-named window (perhaps unwittingly), it won't be
> prevented from acquiring the handle via open('',
> '<name_of_that_window>'), right? That may be unexpected.
> The same goes the other way - the spec subtly implies that because
> window.open('foo', '_unrelated') returns null, the opener will not be
> able to mess with the opened window, but that's not guaranteed given
> that the reference may be leaked by other means, right?
> /mz

Simon Pieters
Opera Software
Received on Thursday, 14 June 2012 07:58:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC