Disable Find-In-Page buttons when no text is entered

chrome/browser/ui/views/find_bar_host.cc

Index: chrome/browser/ui/views/find_bar_host.cc
diff --git a/chrome/browser/ui/views/find_bar_host.cc b/chrome/browser/ui/views/find_bar_host.cc
index 283d963c919ac76b1c404f675c0288fadc9a01ee..a3fde9eca25b946edf4291784778e5368a86d8ea 100644
--- a/chrome/browser/ui/views/find_bar_host.cc
+++ b/chrome/browser/ui/views/find_bar_host.cc
@@ -141,12 +141,10 @@ gfx::Range FindBarHost::GetSelectedRange() {
 
 void FindBarHost::UpdateUIForFindResult(const FindNotificationDetails& result,
                                         const base::string16& find_text) {
-  // Make sure match count is clear. It may get set again in UpdateForResult
-  // if enough data is available.
-  find_bar_view()->ClearMatchCount();
-
   if (!find_text.empty())
     find_bar_view()->UpdateForResult(result, find_text);
+  else
+    find_bar_view()->ClearMatchCount();

[msw, 2016/03/14 17:30:10]

AFAICT, the regression was just from FindBarView::UpdateMatchCountAppearance's
&& -> || change; shouldn't reverting that be sufficient? Why do we want to
change this? (explain in CL description or comment here)

[Mario Pistrich, 2016/03/14 17:52:46]

Reverting only the change of && -> || would reintroduce the initial bug
(https://crrev.com/1660273003).

FindBarView::UpdateMatchCountAppearance was the wrong place to fix the issue.
The initial bug is caused by always calling FindBarView::ClearMatchCount,
regardless of |find_text|. This temporarily disables the buttons and causes the
focus to jump to the close button (if they were focused before).
If FindBarView::ClearMatchCount is only called when the text is empty, the focus
stays on the buttons as they are not getting temporarily disabled.

[msw, 2016/03/14 18:10:32]

Okay, that's reasonable; thanks for the fix and explanation.

 
   // We now need to check if the window is obscuring the search results.
   MoveWindowIfNecessary(result.selection_rect());