PlzNavigate: properly update NavigationHandle for 204/205 and download responses

content/browser/frame_host/navigation_handle_impl.cc

Index: content/browser/frame_host/navigation_handle_impl.cc
diff --git a/content/browser/frame_host/navigation_handle_impl.cc b/content/browser/frame_host/navigation_handle_impl.cc
index f2b2f133ddb19e898c42a356464ef428bd77a875..bbcdcfed714ce72c31ee6e791299a06d76325ca9 100644
--- a/content/browser/frame_host/navigation_handle_impl.cc
+++ b/content/browser/frame_host/navigation_handle_impl.cc
@@ -623,6 +623,23 @@ NavigationHandleImpl::CheckWillProcessResponse() {
   DCHECK(state_ == WILL_PROCESS_RESPONSE || state_ == DEFERRING_RESPONSE);
   DCHECK(state_ != WILL_PROCESS_RESPONSE || next_index_ == 0);
   DCHECK(state_ != DEFERRING_RESPONSE || next_index_ != 0);
+
+  // HTTP 204 (No Content) and HTTP 205 (Reset Content) responses should not
+  // commit; they leave the frame showing the previous page.
+  const bool is_204_205_response =

[clamy, 2016/11/25 10:46:00]

I'm still not super happy about the code flow here for several reasons:
1) Architecturally, this function is supposed to go through all the throttles
and check their results. It's weird to have some special case above which
cancels things. I would prefer we cancel things in WillProcessResponse before we
call this function.
2) More importantly, this will now cause us to possibly spawn a process in
downloads and 204, 205s only to delete it moments later. This is quite wasteful
IMO, so I'd like to avoid that.

In order to avoid the issue above, I don't see a better way but to merge
NavigationRequest & NavigationHandle. This is something I've been wanting to do
eventually when PlzNavigate ships, so I'll have a try at it and see what it
looks like. In the meantime, I'd suggest splitting the CL in two, with the part
about propagating the is_download bit in one CL, and the part about handling
204/205s in NavigationHandle in another.

[yzshen1, 2016/11/28 22:03:59]

Done.
It seems to me that one simple way to avoid this is to split the current
NavigationHandleImpl::WillProcessResponse() into two calls, e.g. (better names
needed):
 - UpdateResponseInfo() which just sets response
header/is_download/is_stream/etc. and
 - ThrottleCheckForWillProcessResponse() which runs the throttle checks.

And then in NavigationRequest::OnResponseStarted(), we do:

=============================================
...
navigation_handle_->UpdateResponseInfo(...);

if (navigation is 204/205 or download) {
  frame_tree_node_->navigator()->DiscardPendingEntryIfNeeded(
        navigation_handle_.get());
  frame_tree_node_->ResetNavigationRequest(false);
  return;
}

// select appropriate renderer, maybe spawn new process.

navigation_handle_->ThrottleCheckForWillProcessResponse();
=============================================

If merging NavigationRequest/NavigationHandle will take a while to happen, maybe
we could do such a simple fix so that the issue won't block some browser tests
or shipping PlzNavigation.
I have created a separate CL for propagating is_download/is_stream/request_id:
https://codereview.chromium.org/2537593002/

[clamy, 2016/11/30 17:44:03]

Yes this is something we could do as well. Let me first see if I can get to a CL
with the merge quickly enough, otnerwise we'll move to the code you suggested.
Thanks!

+      response_headers_ && (response_headers_->response_code() == 204 ||
+                            response_headers_->response_code() == 205);
+
+  // No need to cancel in non-PlzNavigate case. In that case, we will get
+  // DidFailProvisionalLoadWithError notification from the renderer to abort the
+  // navigation.
+  if (IsBrowserSideNavigationEnabled() &&
+      (is_204_205_response || is_download_)) {
+    net_error_code_ = net::ERR_ABORTED;
+    state_ = CANCELING;
+    return NavigationThrottle::CANCEL_AND_IGNORE;
+  }
+
   for (size_t i = next_index_; i < throttles_.size(); ++i) {
     NavigationThrottle::ThrottleCheckResult result =
         throttles_[i]->WillProcessResponse();