-
lukasza authored
Before this CL, the opener would be lost: 1. When creating the BackgroundContents: 1.1. The call from WebContentsImpl::CreateNewWindow to Browser::ShouldCreateWebContents didn't propagate |opener| 1.2. WebContents::CreateWithSessionStorage ignored opener-related fields in WebContents::CreateParams. 2. When inspecting the opener - WebContents::GetOpener used to return WebContents rather than RenderFrameHost (misrepresenting an opener that is a subframe). This CL fixes this by: 1. Adding an |opener| parameter to WebContentsDelegate::ShouldCreateWebContents 2. Modifying constructor of BackgroundContents to take a new |opener| parameter and to pass it to WebContents::CreateParams. 3. Modifying WebContents::CreateWithSessionStorage so that it sets the opener on the newly created contents. 4. Changing WebContents::GetOpener and WebContents::GetOriginalOpener methods to return RenderFrameHost. The accurate opener was originally needed for a planned but ultimately abandoned UMA (see https://crbug.com/718516), but having an accurate opener is desirable in general. This CL re-enables AppBackgroundPageApiTest.OpenThenClose which was disabled due to flakiness 4 years ago. This test is where the verification of the opener has to go. I cannot repro the flakiness when trying the test locally (i.e. running the test 30 times individually, and 20 times as part of the whole AppBackgroundPageApiTest suite) or on the trybots (I've tried 3 x win_chromium_rel_ng, linux_chromium_rel_ng and mac_chromium_rel_ng). BUG=165644, 724280 Review-Url: https://codereview.chromium.org/2882513005 Cr-Commit-Position: refs/heads/master@{#477169}
6f8ac625