Clean up NativeTheme (particularly CommonTheme).

chrome/browser/ui/views/profiles/profile_chooser_view.cc

Index: chrome/browser/ui/views/profiles/profile_chooser_view.cc
diff --git a/chrome/browser/ui/views/profiles/profile_chooser_view.cc b/chrome/browser/ui/views/profiles/profile_chooser_view.cc
index b6a9c1cd47887091bf6e63d52c509a070ee7e829..7039777e9d73747b580ed6e10b28b17d87e20baf 100644
--- a/chrome/browser/ui/views/profiles/profile_chooser_view.cc
+++ b/chrome/browser/ui/views/profiles/profile_chooser_view.cc
@@ -220,8 +220,7 @@ class BackgroundColorHoverButton : public views::LabelButton {
   void OnPaint(gfx::Canvas* canvas) override {
     if ((state() == STATE_PRESSED) ||
         (state() == STATE_HOVERED)) {
-      canvas->DrawColor(GetNativeTheme()->GetSystemColor(
-          ui::NativeTheme::kColorId_ButtonHoverBackgroundColor));

[Evan Stade, 2016/09/30 18:02:36]

one reason this was confusing is because it's not applied to anything that
actually looks like a button (these "buttons" look more like menu items), and
isn't used at all in normal controls (i.e. ui/views/controls).

[tdanderson, 2016/09/30 21:00:56]

Acknowledged. So should a TODO be then to replace the hard-coded use of 0xEAEAEA
here with a more consistently-used color choice?

[Evan Stade, 2016/09/30 22:18:59]

I did put a TODO in the cocoa version of this code. Probably what should
actually happen is this gets an ink drop highlight, and this color then goes
away.

+      canvas->DrawColor(SkColorSetRGB(0xEA, 0xEA, 0xEA));
     }
     LabelButton::OnPaint(canvas);
   }