Handle RenderProcessHostImpl::SetBackgrounded on Windows

content/child/child_thread_impl.cc

Index: content/child/child_thread_impl.cc
diff --git a/content/child/child_thread_impl.cc b/content/child/child_thread_impl.cc
index 55686062938b64308c01645f7b423514418ed28d..5df66318d42a5cc76c8f9307976153f4f4f72691 100644
--- a/content/child/child_thread_impl.cc
+++ b/content/child/child_thread_impl.cc
@@ -17,6 +17,7 @@
 #include "base/logging.h"
 #include "base/message_loop/message_loop.h"
 #include "base/message_loop/timer_slack.h"
+#include "base/metrics/field_trial.h"
 #include "base/process/kill.h"
 #include "base/process/process_handle.h"
 #include "base/strings/string_number_conversions.h"
@@ -649,6 +650,23 @@ void ChildThreadImpl::OnProcessBackgrounded(bool background) {
   if (background)
     timer_slack = base::TIMER_SLACK_MAXIMUM;
   base::MessageLoop::current()->SetTimerSlack(timer_slack);
+
+#ifdef OS_WIN
+  // Windows Vista+ has a fancy process backgrounding mode that can only be set
+  // from within the process. This used to be how chrome set its renderers into
+  // background mode on Windows but was removed due to http://crbug.com/398103.
+  // As we experiment with bringing back some other form of background mode for
+  // hidden renderers, add a bucket to allow us to trigger this undesired method
+  // of setting background state in order to confirm that the metrics which were
+  // added to prevent regressions on the aforementioned issue indeed catch such
+  // regressions and are thus a reliable way to confirm that our latest proposal
+  // doesn't cause such issues. TODO(gab): Remove this once the experiment is
+  // over (http://crbug.com/458594).
+  base::FieldTrial* trial =
+      base::FieldTrialList::Find("BackgroundRendererProcesses");
+  if (trial && trial->group_name() == "AllowBackgroundModeFromRenderer")
+    base::Process::Current().SetProcessBackgrounded(background);
+#endif  // OS_WIN
 }
 
 }  // namespace content