commit dd9a414abfcc248c94dca646d85741cf7c7d956e
author Ehsan Karamad <ekaramad@chromium.org> Tue Dec 04 20:38:20 2018
committer Commit Bot <commit-bot@chromium.org> Tue Dec 04 20:38:20 2018
tree d69cc4b52838728a7af3cf5aa6c0135761b6af92
parent e7ab4d1cfd8f7ba99895ac2be734baf3d4f5a5a2

WebContents should attach after navigations commit

To accommodate attaching MimeHandlerViewGuest though a proxy, the
FrameTreeNode is first navigated to about:blank. The current logic in
FrameNavigationHelper waits for the first commit to about:blank and
then continues the attach process. This current behavior has some
problems which this CL tries to resolve.

1- The helper class listens to WebContentsObserver::DidFinishNavigation
to find out when the navigation in the plugin frame commits; then
immediately attaches to the outer WebContents. This is incorrect as
attaching will synchronously destroy the RenderFrameHost which causes
issues with other observers of the navigations in that frame
(NavigationHandle::GetRenderFrameHost() becomes invalid.

2- There could be many queued up navigations to about:blank and some
of them will commit after attach which causes the same problem as 1).

To address issue 1), this CL will post task the attach to give all the
observers the chance to observe the committed navigation. To address
issue 2) new APIs are introduced to content layer which help to reset
a frame's state (navigation requests and loading state) prior to
attaching.

The CL will also enable a test which was disabled due to crashes caused
by the mentioned problems above.

Bug: 897971, 659750
Change-Id: Ie26a7ca644dcbdb1b18e5a659119ea2f46719c0a
Reviewed-on: https://chromium-review.googlesource.com/c/1298354
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#613683}