commit | 27caae83cb530daaf49f9a38793e427cdf493a65 | [log] [tgz] |
---|---|---|
author | Alex Moshchuk <alexmos@chromium.org> | Mon Sep 11 23:11:18 2017 |
committer | Commit Bot <commit-bot@chromium.org> | Mon Sep 11 23:11:18 2017 |
tree | c03c0737831e313144714bebf37c2568d9a6391b | |
parent | 158a7a01ceb96fd019e996e3501d2fd2995bebb2 [diff] |
Always create a proxy for cross-process navigations. Previously, if a frame F navigated cross-process from a.com to b.com, and this was the first navigation to the b.com process in that BrowsingInstance, we did the following: 1. Create proxies for all frames in FrameTrees on F's opener chain. 2. Create proxies for all frames in F's FrameTree, except for F and its subtree. 3. If F is a main frame: 3a. Create a new active RenderView, which also creates the main frame, already swapped into the tree even though it's still pending and may never commit. Otherwise, if F is a cross-process subframe: 3b. send a CreateFrame IPC, referencing the parent proxy, which should've been created in step 2. This flow breaks down if, while the navigation in F is still pending, other frames in the same BrowsingInstance also navigate to b.com and then try to interact with F (where the current RFH is still at a.com). For example, if F is a main frame, and a subframe of F at a.com navigates to b.com, the subframe won't find the parent proxy for F, because we didn't create one in step 3a. This crashes on CHECK(parent) in CreateFrame(). Furthermore, if the subframe commits first, it should be able to reference F. For example, if the subframe sends a postMessage to F, that should go to F's proxy in b.com, which should forward it to F's current RenderFrame, which is still in a.com. So there should be a proxy created for F in step 3a. This is especially important if F never commits. The same kind of race is possible with openers: a frame at C might window.open() a new tab, then the opener frame starts a cross-process navigation to D, then the opened tab also starts a cross-process navigation to D. If the opener's navigation never succeeds but the opened tab's does, the opened tab at D should still be able to communicate with its old opener at C. To address these races, this CL changes step 2, so that when a frame navigates cross-process, we pre-create a proxy for that frame in the new SiteInstance for cases where other frames might also navigate to the same new SiteInstance and script this frame. This switches the frame creation/navigation in steps 3a or 3b to instead follow the remote-to-local navigation path, i.e., sending the CreateFrame IPC and using the existing-proxy (CreateProvisional) flow. As part of the fix, RenderViewCreated is changed to also be generated for RVHs created for provisional main frame navigations, and RenderViewHostImpl::GetMainFrame() will also return pending main frame RFH if it exists. This keeps the embedder's assumptions about RenderViewHost valid. Longer-term, these APIs should be deprecated and migrated to use RenderFrameCreated. This followup work will be tracked in issue 763548. Bug: 756790, 626802, 591478, 760403 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation Change-Id: I6b85d135ec1e507110a51c9fe1b2a05754633a50 Reviewed-on: https://chromium-review.googlesource.com/636786 Reviewed-by: Emily Stark <estark@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Jialiu Lin <jialiul@chromium.org> Reviewed-by: Charlie Reis (slow) <creis@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Commit-Queue: Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/master@{#501081}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure .