When unblocking a WebContents, don't bring it to the front if it is not already.

chrome/browser/ui/browser.cc

Index: chrome/browser/ui/browser.cc
diff --git a/chrome/browser/ui/browser.cc b/chrome/browser/ui/browser.cc
index 4c02948d4ae9543a60c89f9fa0b97db30fb0ee48..79b54b81ddc2717badc753bc6495677852bd3c9e 100644
--- a/chrome/browser/ui/browser.cc
+++ b/chrome/browser/ui/browser.cc
@@ -1900,7 +1900,13 @@ void Browser::SetWebContentsBlocked(content::WebContents* web_contents,
     return;
   }
   tab_strip_model_->SetTabBlocked(index, blocked);
-  if (!blocked && tab_strip_model_->GetActiveWebContents() == web_contents)
+
+  bool browser_active = BrowserList::GetInstance()->GetLastActive() == this;
+  bool contents_is_active =
+      tab_strip_model_->GetActiveWebContents() == web_contents;
+  // If the WebContents is foremost (the active tab in the front-most browser)
+  // and is being unblocked, focus it to make sure that input works again.
+  if (!blocked && contents_is_active && browser_active)

[Lei Zhang, 2016/10/24 22:43:15]

Maybe return early if |blocked| is true?

[Avi (use Gerrit), 2016/10/25 15:07:08]

There are three conditions to focusing it; it feels weird to me to test just
one, unless you're worried about the cost of calculating the others, but how
often does this happen?

[Lei Zhang, 2016/10/25 17:31:43]

I'm not that worried about it. I just saw it from the "it already failed, why
keep going" perspective.

     web_contents->Focus();
 }