GitLab

This is necessary because ThemeProperties::GetDefaultColor() is never actually
reached for COLOR_TOOLBAR_BUTTON_ICON (so the kGoogleGrey100 return in
GetIncognitoColor() was dead code).  ThemeService::GetDefaultColor()
unconditionally uses the tint, which was {-1, -1, -1} in dark mode after
http://crrev.com/688233 .  This approximately restores the behavior from before
that CL, when dark-mode was special-cased for TINT_BUTTONS to just return white.

Another way to solve this would be to remove this code from ThemeService, add
a "return kChromeIconGrey" to GetLightModeColor() for COLOR_TOOLBAR_BUTTON_ICON,
and add processing to browser_theme_pack.cc to compute an override color if the
theme specifies TINT_BUTTONS.  This would change HasCustomColor() to return true
"more accurately" -- i.e. only if the theme customizes the color, instead of
what it does now, which is to return true any time the tint is not a no-op.
Looking at callers of HasCustomColor(COLOR_TOOLBAR_BUTTON_ICON), they seem to
want it to return true in the dark/incognito case, so I've avoided this route
for now, although perhaps these callers could be updated (e.g. to check if the
returned color was non-default or just unconditionally use the returned color as
if it's "custom").

This does not apply the dark tinting to TINT_FRAME*, since doing so will cause
dark mode to darken the frame images of every theme that uses them without
explicitly setting a manual tint (i.e. almost all themes that use custom frame
images).  This is sort of an interesting effect, but would almost certainly be
considered "breaking" these themes.

Bug: 995681
Change-Id: I4dd8a7c24323b5a4caf24b3ad08188f73de028c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1762943
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/master@{#689157}