Remove the SetBackground call during process creation. The benefit

of the call is that we de-prioritize work that is in the background.
Unfortunately, tab creation currently bounces through hidden/unhidden/
hidden/unhidden at least 2x before the tab is visible to the user.
Because we don't know if the tab will be in the foreground (and thus
prevent it from being SetBackgrounded), the right thing to do is to
simply not Background it on startup.

BUG=21884
TEST=none

Review URL: http://codereview.chromium.org/3249006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57870 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 9 insertions, 2 deletions

diff --git a/chrome/browser/renderer_host/browser_render_process_host.cc b/chrome/browser/renderer_host/browser_render_process_host.cc
index 0a27032..83d59f0 100644
--- a/chrome/browser/renderer_host/browser_render_process_host.cc
+++ b/chrome/browser/renderer_host/browser_render_process_host.cc
@@ -972,8 +972,15 @@ void BrowserRenderProcessHost::Observe(NotificationType type,
 }
 
 void BrowserRenderProcessHost::OnProcessLaunched() {
-  // Now that the process is created, set its backgrounding accordingly.
-  SetBackgrounded(backgrounded_);
+  // At this point, we used to set the process priority if it were marked as
+  // backgrounded_.  We don't do that anymore because when we create a process,
+  // we really don't know how it will be used.  If it is backgrounded, and not
+  // yet processed, a stray hung-cpu process (not chrome) can cause pages to
+  // not load at all.  (see http://crbug.com/21884).
+  // If we could perfectly track when a process is created as visible or not,
+  // we could potentially call SetBackgrounded() properly at this point.  But
+  // there are many cases, and no effective way to automate those cases.
+  // I'm choosing correctness over the feature of de-prioritizing this work.
 
   Send(new ViewMsg_SetIsIncognitoProcess(profile()->IsOffTheRecord()));