New issue
Advanced search Search tips

Issue 658402 link

Starred by 2 users
Status: WontFix
Owner:
alex...@chromium.org
Closed: Oct 2016
Cc:
wfh@chromium.org
creis@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Window not findable from frame cross-site from opener

Project Member Reported by lukasza@chromium.org, Oct 21 2016 
Repro steps (tested at r425087):

1. Launch chrome with --site-per-process
2. Navigate via omnibox to
   http://csreis.github.io/tests/cross-site-iframe.html
3. Click "Go cross-site (complex page)" button.

4. Right click on the main frame and inspect / open
   javascript console (console1a).
5. In console1a create a new window:
   > w2 = window.open('', 'window2')
6. Go back to the original page and in console1a verify
   that you CAN find the new window:
   > w2 = window.open('', 'window2')

7. Go back to the original page and right click on
   the cross-site frame and inspect / open
   javascript console (console1b) for the cross-site frame.
8. In console1b, try to find the new window:
   > w2 = window.open('', 'window2')


EXPECTED BEHAVIOR:

Step8 (just like step6) should find the window opened in step5
(because everything in repro steps should be in the same browsing instance)

ACTUAL BEHAVIOR:

Step8 opens a new window (as if it wasn't able to find a window named 'window2').

Comment 1 by alex...@chromium.org, Oct 22 2016

Cc: -alex...@chromium.org
Owner: alex...@chromium.org
Lukasz, I think this is actually intended behavior.  If you try the same steps without --site-per-process, you'll also get a new window in step 8, and you also will see the following message in JS console:

Unsafe JavaScript attempt to initiate navigation for frame with URL 'about:blank' from frame with URL 'https://csreis.github.io/'. The frame attempting navigation is neither same-origin with the target, nor is it the target's parent or opener.

So the --site-per-process behavior is the same, except that we don't output the error message.  

We intentionally don't create the proxy for w2 in the subframe's process for this case, because the subframe isn't allowed to access w2 (i.e., not even look it up by name with window.open).  Only w2's opener, or the opener's ancestors are allowed to do this lookup.  See  issue 511474 , the comments in RenderFrameHostManager::CreateProxiesForNewNamedFrame, and the doc at https://goo.gl/HlddDy for full context.  Please let me know if I missed something.

It didn't seem worth it to create the proxy just for the missing error message in OOPIF scenarios, especially since not having a proxy for something that you aren't supposed to access seems more secure, but we can revisit this if it turns out that there are other observable differences due to not having the proxy around.

Comment 2 by lukasza@chromium.org, Oct 24 2016

Status: WontFix (was: Untriaged)
Thanks for the explanation (and for the links in the description of https://crrev.com/1250473008) - TIL that a browsing context might not be able to find another browsing context in the same browsing instance if it is not "familiar with" that other browsing context.

Given the specs, this seems to be WAI.
►

Sign in to add a comment