-
Lukasz Anforowicz authored
Before this CL, windows (or tabs, panels, etc.) created by chrome.windows.create API form a relationship that is almost, but not quite, like an opener relationship: 1. Unlike in a true opener relationship, the 2 frames (opener and openee) can find each other, but only if they are still in the same process. For example, if only 1 frame navigates cross-process, then the frames won't be able to find each other (for a specific example please see https://crbug.com/713888#c5). 2. Unlike in a true opener relationship, window.opener is not set (and consequently cannot be navigated by the openee). After this CL, chrome.windows.create API forms a true opener relationship *iff* the new parameter - setSelfAsOpener is used. Otherwise, the newly opened window is created in a separate browsing instance. This is required for later restricting named frame lookup to the current browsing instance (see https://crbug.com/718489). The CL establishes a true opener relationship, by having extensions::WindowsCreateFunction::Run pass an opener (a RenderFrameHost*) into chrome::NavigateParams, rather than using |force_new_process_for_new_contents| field which this CL removes. This CL tweaks ExtensionApiTest.WindowsCreateVsBrowsingInstance test so that: - The test is closer to what the hangouts extension does (it navigates both windows to the same web origin and *then* attempts to lookup one window from the other). Without this modification, the test would NOT have caught the hangouts extension regression that was almost introduced by https://crrev.com/2873503002). - The test verifies the opener relationship (i.e. |window.opener|, findability via |window.open|, SiteInstance::IsRelatedSiteInstance) rather than accidental, indirect manifestations of having an opener relationship (i.e. being in the same process or site instance). Relevant automated tests: - Tweaked test: - ExtensionApiTest.WindowsCreateVsSiteInstance (the window.open part passes before and after this CL; the window.opener part + the IsRelatedSiteInstance part only pass after this CL) - Other tests: - AppBackgroundPageApiTest.Basic (hosted app -> background page can violate browsing instance; tests handling of mapping of web urls [full url, not just origin] to extensions) - CtrlClickShouldEndUpInNewProcessTest.* tests (tests for behavior that used to depend on the removed |force_new_process_for_new_contents| field). I have also verified that the Hangouts extension (current prod version - 2017.1019.418.1) works fine before and after this CL (i.e. I have verified that this CL doesn't regress https://crbug.com/597750). Bug: 713888 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation Test: See above. Change-Id: If23ac7b72256bfcd695fc4bc3759a5bd73f4812f Reviewed-on: https://chromium-review.googlesource.com/758801 Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Charlie Reis <creis@chromium.org> Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org> Cr-Commit-Position: refs/heads/master@{#516081}
a4466478