GitLab

It is possible for window objects in <webview> tags to have
window.opener relationships.  In particular, one <webview> can use
window.open('', 'foo') to look up another <webview> which has
window.name equal to 'foo', and update its window.opener to point to
itself.  This triggers an UpdateOpener IPC, which ensures that the new
opener chain has proper proxies so that 'foo' is able to reach any
frame on that chain (see RenderFrameHostManager::DidChangeOpener).

Unfortunately, this had a bug because the proxy creation also tried to
create proxies for the outer delegate (i.e., the chrome app)
SiteInstance, for all frames on the new opener chain, including
subframes.  This is wrong because we intentionally do not want to
expose a guest's subframes to the embedder -- see
RenderFrameHostManager::CreateProxiesForChildFrame(), which
intentionally skips the outer delegate's proxy.  In this case, this
later led to a crash in CreateRenderFrameProxy(), because the proxy we
tried to create for a subframe didn't have a RenderViewHost (which is
intentional -- we do not create a RVH for the outer delegate's
SiteInstance, just the proxy, and only for the guest's main frame).

This CL fixes this by ensuring that we skip the outer delegate
SiteInstance when creating proxies for subframes in
CreateProxiesForSiteInstance(), which is used when updating the opener
chain as well as more generically (e.g., when creating speculative
RenderFrameHosts).  This hopefully will better protect against this
type of bug in the future compared to a more targeted fix in
opener update logic (e.g., if/when we add OOPIF support in
GuestViews).

Change-Id: I6a2e452883faa140a86523b2afda372c62cbdbcb
Bug: 1013553
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1903245Reviewed-by: James MacLean <wjmaclean@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713881}