Resets hover state when ToolbarActionView is dragged

chrome/browser/ui/views/toolbar/toolbar_action_view.cc

Index: chrome/browser/ui/views/toolbar/toolbar_action_view.cc
diff --git a/chrome/browser/ui/views/toolbar/toolbar_action_view.cc b/chrome/browser/ui/views/toolbar/toolbar_action_view.cc
index 37f514008e26851b92a522a89aa171d9ee59ba42..6703918933d9cb56dcd05a14248bb17fad453055 100644
--- a/chrome/browser/ui/views/toolbar/toolbar_action_view.cc
+++ b/chrome/browser/ui/views/toolbar/toolbar_action_view.cc
@@ -199,6 +199,12 @@ gfx::Size ToolbarActionView::GetPreferredSize() const {
                    ToolbarActionsBar::IconHeight());
 }
 
+void ToolbarActionView::OnMouseCaptureLost() {

[Devlin, 2016/03/01 15:00:59]

Why is this in ToolbarActionView instead of a button class?  It looks like
CustomButton has an implementation of OnMouseCaptureLost that does this for
everything *except* dragged views (because starting a drag results in capture
lost)... and I thought that was intentional.  Don't we want the view to remain
"pressed" when we are dragging it around?

[varkha, 2016/03/01 16:32:31]

Yes, I thought so too but wasn't sure if there is more to it. I think with MD
the hovered or pressed state looks bad during a drag, particularly in the app
menu. estade@ pointed this out and we thought it would be OK to remove this
everywhere. I am open to removing InDrag() check from
CustomButton::OnMouseCaptureLost. I think during a drag we give enough feedback
with the drag widget and insertion point to make the pressed / hovered state of
the drag target redundant.

[Evan Stade, 2016/03/01 21:01:17]

The problem is that MD ink drops (which provide hover and pressed effects) look
substantially different from the pre-MD pressed state. So mixing and matching
these (i.e. using ink drops for hover and press, but reverting to pre-md press
effect for drag) looks bad. That's why I suggested just removing it. I think the
change should be MD-only to be conservative.

Does this mean we don't want any effect at all on the dragged button in the
world of MD? That's a question for Sebastien and something to fix down the line
based on his answer. But I'm pretty sure no effect is better than what we have
now.

As far as moving this to CustomButton, that would make sense and it would make
the bookmark bar buttons consistent with the toolbar action buttons... but not
all custom buttons are updated to used ink drops yet so I'd be careful about
determining if some draggable button somewhere were losing this pressed state
despite not having an inkdrop applied to it yet.

+  MenuButton::OnMouseCaptureLost();
+  if (IsHotTracked())
+    SetState(STATE_NORMAL);
+}
+
 bool ToolbarActionView::OnMousePressed(const ui::MouseEvent& event) {
   // views::MenuButton actions are only triggered by left mouse clicks.
   if (event.IsOnlyLeftMouseButton()) {