`opener` should be navigable from a nested frame. |
||||
Issue descriptionThe 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.
,
Oct 2 2017
,
Oct 2 2017
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).
,
Oct 3
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
,
Oct 12
|
||||
►
Sign in to add a comment |
||||
Comment 1 Deleted