- From: Charlie Reis <creis@chromium.org>
- Date: Thu, 14 Jun 2012 10:45:09 -0700
- To: James Graham <jgraham@opera.com>
- Cc: whatwg@lists.whatwg.org, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Jun 14, 2012 at 4:04 AM, James Graham <jgraham@opera.com> wrote: > On 06/14/2012 04:06 AM, Boris Zbarsky wrote: > >> On 6/13/12 7:44 PM, Michal Zalewski wrote: >> >>> The degree of separation between browsing contexts is intuitive in the >>> case of Chrome >>> >> >> Except it's not, because Chrome will sometimes put things in the same >> process when they could have gone in different ones, based on whatever >> heuristics it uses for deciding whether it's spawned enough processes. >> >> True, though that doesn't mean they need to share the same name scope. Right now, you're correct: Chrome does allow this named window discovery when renderer processes are re-used. However, we could probably look into using a separate WebKit PageGroup when re-using a process so that names stay local to their unit of related browsing contexts. > 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? >>> >> >> The spec needs to require that this be prevented.... >> > > So AFAICT the spec does require that this is prevented for unrelated > browsing contexts, except in the case where the two are same-origin which > is allowed but with some fuzzy condition about "[if] the user agent > determines that the two browsing contexts are related enough that it is ok > if they reach each other". As far as I can tell only Gecko implements that > and it seems reasonable that others wouldn't want to have behaviour that > requires multiple event loops to interact (assuming one event loop per unit > of related browsing context). > > Therefore I think that part of the spec should be changed to only reuse > the same named window within a single unit of related browsing context. > I would be happy to see that happen, for the same reason as you (allowing user agents to have one event loop or process per unit of related browsing contexts). I'm not sure how to interpret the current wording of the spec in this case. I do observe that Safari, IE, and even Opera currently allow windows in unrelated contexts to discover named windows, though. Just do a window.open("foo.html", "foo") from two independently opened windows and they'll both target the same "foo" window. As a result, making unrelated browsing contexts inaccessible to each other would probably require changes to most user agents. I'm ok either way: allowing named but unrelated windows to be discovered or not. Charlie
Received on Thursday, 14 June 2012 17:45:49 UTC