Index: content/browser/frame_host/navigation_request.cc |
diff --git a/content/browser/frame_host/navigation_request.cc b/content/browser/frame_host/navigation_request.cc |
index 39d1cdda2295ceea1f59a44cc804be47a981b169..a4c3c462ebf87c5d6d10b20c719039eff8e69c03 100644 |
--- a/content/browser/frame_host/navigation_request.cc |
+++ b/content/browser/frame_host/navigation_request.cc |
@@ -569,9 +569,23 @@ void NavigationRequest::OnRequestFailed(bool has_stale_copy_in_cache, |
return; |
} |
- // Select an appropriate renderer to show the error page. |
- RenderFrameHostImpl* render_frame_host = |
- frame_tree_node_->render_manager()->GetFrameHostForNavigation(*this); |
+ // There are two types of error pages that need to be handled differently. |
+ // * Error pages resulting from blocking the request, because the original |
+ // document wasn't even allowed to make the request. In such case, |
+ // the error pages should be committed in the process of the original |
+ // document, to avoid creating a process for the destination. |
+ // * Error pages resulting from either network outage (no network, DNS |
+ // error, etc) or similar cases, where the user can reasonably expect that |
+ // a reload at a later point in time can be successful. Such error pages |
+ // do belong to the process that will host the destination URL, as a |
+ // reload will end up committing in that process anyway. |
+ RenderFrameHostImpl* render_frame_host = nullptr; |
+ if (net_error == net::ERR_BLOCKED_BY_CLIENT) { |
nasko
2017/03/07 07:08:12
It turns out that the webRequest API blocking navi
Charlie Reis
2017/03/09 00:43:34
What's the problem with using the current RFH for
nasko
2017/03/09 07:24:09
I've done a lot of debugging but cannot see why th
|
+ render_frame_host = frame_tree_node_->current_frame_host(); |
+ } else { |
+ render_frame_host = |
+ frame_tree_node_->render_manager()->GetFrameHostForNavigation(*this); |
+ } |
// Don't ask the renderer to commit an URL if the browser will kill it when |
// it does. |