Add a field trial to delay all resource requests by thread hops.

chrome/browser/renderer_host/thread_hop_resource_throttle.cc

Index: chrome/browser/renderer_host/thread_hop_resource_throttle.cc
diff --git a/chrome/browser/renderer_host/thread_hop_resource_throttle.cc b/chrome/browser/renderer_host/thread_hop_resource_throttle.cc
new file mode 100644
index 0000000000000000000000000000000000000000..cdd71fe66646c458426ffb92c029231621ca5371
--- /dev/null
+++ b/chrome/browser/renderer_host/thread_hop_resource_throttle.cc
@@ -0,0 +1,59 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/renderer_host/thread_hop_resource_throttle.h"
+
+#include "base/bind.h"
+#include "base/bind_helpers.h"
+#include "base/location.h"
+#include "base/metrics/field_trial.h"
+#include "base/metrics/histogram_macros.h"
+#include "base/strings/string_util.h"
+#include "base/time/time.h"
+#include "content/public/browser/browser_thread.h"
+#include "content/public/browser/resource_controller.h"
+
+ThreadHopResourceThrottle::ThreadHopResourceThrottle() : weak_factory_(this) {}
+
+ThreadHopResourceThrottle::~ThreadHopResourceThrottle() {}
+
+bool ThreadHopResourceThrottle::IsEnabled() {
+  const std::string group_name =
+      base::FieldTrialList::FindFullName("ThreadHopResourceThrottle");
+  return base::StartsWith(group_name, "Enabled", base::CompareCase::SENSITIVE);
+}
+
+void ThreadHopResourceThrottle::WillStartRequest(bool* defer) {
+  *defer = true;
+  ResumeAfterThreadHop();
+}
+
+void ThreadHopResourceThrottle::WillRedirectRequest(
+    const net::RedirectInfo& redirect_info,
+    bool* defer) {
+  *defer = true;
+  ResumeAfterThreadHop();
+}
+
+void ThreadHopResourceThrottle::WillProcessResponse(bool* defer) {
+  *defer = true;
+  ResumeAfterThreadHop();
+}
+
+const char* ThreadHopResourceThrottle::GetNameForLogging() const {
+  return "ThreadHopResourceThrottle";
+}
+
+void ThreadHopResourceThrottle::ResumeAfterThreadHop() {
+  content::BrowserThread::PostTaskAndReply(

[sky, 2015/10/06 20:06:03]

What would happen if we ran a nested message loop during this time? Would the
task be blocked until the nested message loop completed?

[davidben, 2015/10/06 20:18:00]

I expect it would, yeah, unless that nested message loop runs random other tasks
of ours. I think a lot of those dialogs now happen on other threads (see
BaseShellDialogImpl), but that is definitely one thing that we'd end up blocking
on, were we to go this route.

I know in the past, windowed mode NPAPI on Windows could cause a things to block
like UI -> plugin -> renderer, which is why sync IPCs that don't spin up
renderer nested message loops can't be handled on the UI thread on Windows. jam
tells me this is no longer an issue with NPAPI gone.

https://code.google.com/p/chromium/codesearch#chromium/src/content/public/bro...

I'd expect such a loop would also block much of anything else that happens since
a lot of the browser hits the UI thread for some reason or another.


The alternative would be to mirror more state on the IO thread since a number of
things want more detailed information at resource loader handling, but we don't
currently have that information. (Except for extensions and WebView, which
maintains adhoc maps.) I'd originally proposed toying with an RFHIOState or
similar sort of object, but I got pushback and was asked to look into the
feasibility to just hitting the UI thread more. Hence this field trial.

+      content::BrowserThread::UI, FROM_HERE, base::Bind(&base::DoNothing),
+      base::Bind(&ThreadHopResourceThrottle::Resume, weak_factory_.GetWeakPtr(),
+                 base::TimeTicks::Now()));
+}
+
+void ThreadHopResourceThrottle::Resume(const base::TimeTicks& time) {
+  UMA_HISTOGRAM_TIMES("Net.ThreadHopResourceThrottleTime",
+                      base::TimeTicks::Now() - time);
+  controller()->Resume();
+}