[Mac] Use CommonTheme for the new avatar menu button hover background

chrome/browser/ui/cocoa/profiles/profile_chooser_controller.mm

Index: chrome/browser/ui/cocoa/profiles/profile_chooser_controller.mm
diff --git a/chrome/browser/ui/cocoa/profiles/profile_chooser_controller.mm b/chrome/browser/ui/cocoa/profiles/profile_chooser_controller.mm
index 2c62acb7d082ad7d16b4e27bb93e2143f35fe062..3797f25a46307819a03224e162e16fcf22f6f55d 100644
--- a/chrome/browser/ui/cocoa/profiles/profile_chooser_controller.mm
+++ b/chrome/browser/ui/cocoa/profiles/profile_chooser_controller.mm
@@ -60,6 +60,7 @@
 #include "ui/base/resource/resource_bundle.h"
 #include "ui/gfx/image/image.h"
 #include "ui/gfx/text_elider.h"
+#include "ui/native_theme/common_theme.h"
 #include "ui/native_theme/native_theme.h"
 
 namespace {
@@ -642,9 +643,13 @@ class ActiveProfileObserverBridge : public AvatarMenuObserver,
     backgroundColor:(NSColor*)backgroundColor {
   if ((self = [super initWithFrame:frameRect])) {
     backgroundColor_.reset([backgroundColor retain]);
-    hoverColor_.reset([gfx::SkColorToCalibratedNSColor(
-        ui::NativeTheme::instance()->GetSystemColor(
-            ui::NativeTheme::kColorId_ButtonHoverBackgroundColor)) retain]);
+    // Use a color from the common theme, since this button is not trying to
+    // look like a native control.
+    SkColor hoverColor;
+    bool found = ui::CommonThemeGetSystemColor(
+        ui::NativeTheme::kColorId_ButtonHoverBackgroundColor, &hoverColor);

[groby-ooo-7-16, 2014/08/06 00:05:25]

I wish CommonTheme followed the NativeTheme API and didn't return a bool :(

[tapted, 2014/08/06 01:49:09]

Yeah :/ - I think it's to avoid something special to handle SkColor(0), although
100% transparent black is a pretty useless colour (and the SystemColor tests
I've added treat it as an error anyway).

+    DCHECK(found);
+    hoverColor_.reset([gfx::SkColorToSRGBNSColor(hoverColor) retain]);

[tapted, 2014/08/04 03:11:47]

Note it's using sRGB rather than "Calibrated" here. sRGB is the colorspace that
PNGs, CSS, iOS and Windows use by default [more info: http://crbug.com/254361 ].
This might be darker than previously -- sRGB values are encoded with a gamma of
2.2 which became the default in Snow Leopard [1], but older NSColor methods tend
to use a gamma of 1.8.

Seems NSColor documentation [2] now also recommends srgb: "Where possible, it is
preferable to specify the colorspace explicitly using the
colorWithSRGBRed:green:blue:alpha: or colorWithGenericGamma22White:alpha:
method."

[1] http://support.apple.com/kb/ht3712
[2]
https://developer.apple.com/library/mac/documentation/cocoa/Reference/Applica...:

[groby-ooo-7-16, 2014/08/06 00:05:24]

+1 on fixing the color space. (I believe I suggested "calibrated" here, so
that's my fault)

But N.B. that half of our colors still use SkColorToCalibratedNSColor. Not
directly relevant to the bug, but should we add a presubmit that prevents use of
calibrated?

[tapted, 2014/08/06 01:49:09]

Good idea - I think something like https://codereview.chromium.org/448483003
will do this, but I'll start some discussions first (and update the
cocoa-dos-and-don'ts page). There was some uncertainty when it came up before.
However, since the NSColor documentation has been updated to suggest srgb over
other methods, I think it's more clear.

 
     [self setBordered:NO];
     [self setFont:[NSFont labelFontOfSize:kTextFontSize]];