Adds a test that verifies that navigating in the unload handler while

Adds a test that verifies that navigating in the unload handler while
performing a process transfer for a subframe doesn't crash the browser.

BUG=613244
Committed: https://crrev.com/18ed527d63e722878207ae59b2f5744fca338152
Cr-Commit-Position: refs/heads/master@{#418034}

[lfg, 2016-09-12 18:57:44]

The CQ bit was checked by lfg@chromium.org to run a CQ dry run

[lfg, 2016-09-12 18:58:04]

lfg@chromium.org changed reviewers:
+ creis@chromium.org

[lfg, 2016-09-12 18:58:05]

Charlie, please take a look.

[commit-bot: I haz the power, 2016-09-12 18:58:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Charlie Reis, 2016-09-12 19:15:48]

LGTM!  So happy that you blocked navigations in the unload handler.

Is it possible for WebFrame::swap to return false anymore?  I'm wondering if
there's any cleanup we can do to RenderFrameImpl::OnSwapOut, which is littered
with references to the case where the swap fails.

[lfg, 2016-09-12 19:20:47]

On 2016/09/12 19:15:48, Charlie Reis (slow) wrote:
> LGTM!  So happy that you blocked navigations in the unload handler.
> 
> Is it possible for WebFrame::swap to return false anymore?  I'm wondering if
> there's any cleanup we can do to RenderFrameImpl::OnSwapOut, which is littered
> with references to the case where the swap fails.

Yes, unfortunately we still need to handle that case. If we have an A->B->A
frame tree, when B is navigating, the subframe A can synchronously script the
top level frame and detach B's subframe, and in that case WebFrame::swap
returns false.

[lfg, 2016-09-12 19:30:05]

The CQ bit was checked by lfg@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-12 19:30:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[lfg, 2016-09-12 19:46:38]

On 2016/09/12 19:20:47, lfg wrote:
> On 2016/09/12 19:15:48, Charlie Reis (slow) wrote:
> > LGTM!  So happy that you blocked navigations in the unload handler.
> > 
> > Is it possible for WebFrame::swap to return false anymore?  I'm wondering if
> > there's any cleanup we can do to RenderFrameImpl::OnSwapOut, which is
littered
> > with references to the case where the swap fails.
> 
> Yes, unfortunately we still need to handle that case. If we have an A->B->A
> frame tree, when B is navigating, the subframe A can synchronously script the
> top level frame and detach B's subframe, and in that case WebFrame::swap
> returns false.

There was one TODO that can be removed from OnSwapOut (the one that says we
need to handle navigation during swap).

[Charlie Reis, 2016-09-12 19:48:17]

Thanks for clarifying.  LGTM.

[commit-bot: I haz the power, 2016-09-12 20:28:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-12 20:28:55]

Dry run: This issue passed the CQ dry run.

[lfg, 2016-09-12 20:42:07]

The CQ bit was checked by lfg@chromium.org

[commit-bot: I haz the power, 2016-09-12 20:42:44]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-12 20:47:33]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-12 20:49:18]

Description was changed from

==========
Adds a test that verifies that navigating in the unload handler while
performing a process transfer for a subframe doesn't crash the browser.

BUG=613244
==========

to

==========
Adds a test that verifies that navigating in the unload handler while
performing a process transfer for a subframe doesn't crash the browser.

BUG=613244

Committed: https://crrev.com/18ed527d63e722878207ae59b2f5744fca338152
Cr-Commit-Position: refs/heads/master@{#418034}
==========

[commit-bot: I haz the power, 2016-09-12 20:49:20]

Patchset 2 (id:??) landed as
https://crrev.com/18ed527d63e722878207ae59b2f5744fca338152
Cr-Commit-Position: refs/heads/master@{#418034}