New issue
Advanced search Search tips

Issue 702545 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

`opener` should be navigable from a nested frame.

Project Member Reported by mkwst@chromium.org, Mar 17 2017

Issue description

The last test in https://github.com/w3c/web-platform-tests/pull/2356 shows that Chrome diverges from Firefox with regard to `window.opener` navigation from within a frame. As discussed on that issue, it doesn't add much of anything from a security perspective, as the frame can navigate the top-level document and then navigate its opener. We should align with Firefox.
 

Comment 1 Deleted

Comment 2 by nasko@chromium.org, Oct 2 2017

Cc: alex...@chromium.org dcheng@chromium.org
If we do decide to change this, in addition to relaxing the check in Blink, we should also double-check that we create all the necessary proxies so that this works with OOPIFs.  I *think* we should be fine for the case in that test (i.e., parent.opener should always have a proxy) because RenderFrameHostManager::CollectOpenerFrameTrees traverses openers of all nodes in the frame tree, but in some other cases we rely on what's reachable according to spec to avoid creating certain proxies (e.g., see RenderFrameHostManager::CreateProxiesForNewNamedFrame).
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 3

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment