Fixes ink drop being "stuck" on when losing focus.

ui/views/controls/button/custom_button.cc

Index: ui/views/controls/button/custom_button.cc
diff --git a/ui/views/controls/button/custom_button.cc b/ui/views/controls/button/custom_button.cc
index 7664f615332918ad415186babc7dc628cbfe803c..a4384746569feb17003d0d86c04293a521feeeed 100644
--- a/ui/views/controls/button/custom_button.cc
+++ b/ui/views/controls/button/custom_button.cc
@@ -241,12 +241,12 @@ bool CustomButton::OnKeyPressed(const ui::KeyEvent& event) {
 }
 
 bool CustomButton::OnKeyReleased(const ui::KeyEvent& event) {
-  if ((state_ == STATE_DISABLED) || (event.key_code() != ui::VKEY_SPACE))
-    return false;
-
-  SetState(STATE_NORMAL);
-  NotifyClick(event);
-  return true;
+  if ((state_ == STATE_PRESSED) && (event.key_code() == ui::VKEY_SPACE)) {
+    SetState(STATE_NORMAL);
+    NotifyClick(event);
+    return true;
+  }
+  return false;
 }
 
 void CustomButton::OnGestureEvent(ui::GestureEvent* event) {
@@ -371,8 +371,11 @@ void CustomButton::ViewHierarchyChanged(
 
 void CustomButton::OnBlur() {
   Button::OnBlur();
-  if (IsHotTracked())
+  if (IsHotTracked() || state_ == STATE_PRESSED) {

[bruthig, 2016/05/31 14:20:40]

This opens up the following edge case:

1. Press and hold left mouse button
2. Obtain keyboard focus (still holding left mouse down)
3. Lose keyboard focus (i.e. OnBlur() is called)
4. Release left mouse button (which presumably triggers the button action)

I believe at step 4 there will be no visual indication that the button is armed
and firing an action due to the mouse release may catch a user off guard. 
Although it appears as though this was also a problem pre-MD however so I'm not
sure which is the lesser of two evils.

Would it be possible to 'unarm' the button for mouse and keyboard when OnBlur()
is called?  And would this make sense?  And if we go that far, we should also be
considering gesture events too.

sky@, what are your thoughts on this?

[bruthig, 2016/05/31 14:23:42]

At the very least I do believe this change is an improvement as it prevents the
ripple from getting stuck on.  But we should at the very least create an issue
or a TODO to make buttons work more robustly between the three different input
methods.

     SetState(STATE_NORMAL);
+    if (ink_drop_delegate())
+      ink_drop_delegate()->OnAction(views::InkDropState::HIDDEN);
+  }
 }
 
 bool CustomButton::ShouldShowInkDropForFocus() const {