WebContents could be blocked after pending cross-site navigation is canceled.

content/browser/frame_host/render_frame_host_impl.cc

Index: content/browser/frame_host/render_frame_host_impl.cc
diff --git a/content/browser/frame_host/render_frame_host_impl.cc b/content/browser/frame_host/render_frame_host_impl.cc
index dc1393cb65da8e3bbe1ed4a689f196bc7e20f52c..a884b43f87ac15879c97fc8991d5b8a913928572 100644
--- a/content/browser/frame_host/render_frame_host_impl.cc
+++ b/content/browser/frame_host/render_frame_host_impl.cc
@@ -528,8 +528,15 @@ void RenderFrameHostImpl::OnBeforeUnloadACK(
   // If this renderer navigated while the beforeunload request was in flight, we
   // may have cleared this state in OnNavigate, in which case we can ignore
   // this message.
+  // However renderer might also be swapped out but we still want to proceed
+  // with navigation, otherwise it would block whole web_contents. This can
+  // happen when pending cross-site navigation is canceled by second one just
+  // before OnNavigate, current (loaded) RVH is waiting for commit but second
+  // navigation is started from the beginning.
   if (!render_view_host_->is_waiting_for_beforeunload_ack_ ||
-      render_view_host_->rvh_state_ != RenderViewHostImpl::STATE_DEFAULT) {
+      (render_view_host_->rvh_state_ != RenderViewHostImpl::STATE_DEFAULT &&
+       render_view_host_->rvh_state_ !=
+           RenderViewHostImpl::STATE_WAITING_FOR_COMMIT)) {

[Charlie Reis, 2014/03/28 16:43:20]

This doesn't seem right to me, since I don't yet see what's special about the
WAITING_FOR_COMMIT state.  Couldn't we be in a related state and hit the same
problem?  I'm wondering if we should be checking this in another way, using
something like IsRVHStateActive.

Note that this check used to look like this when it was in RVH, before the state
machine was introduced:
  if (!is_waiting_for_beforeunload_ack_ || is_swapped_out_)

Context:
https://codereview.chromium.org/88503002/diff/1740001/content/browser/rendere...

     return;
   }