Use style::CONTEXT_TEXTFIELD for Combobox and Textfield

chrome/browser/ui/views/harmony/harmony_typography_provider.cc

Index: chrome/browser/ui/views/harmony/harmony_typography_provider.cc
diff --git a/chrome/browser/ui/views/harmony/harmony_typography_provider.cc b/chrome/browser/ui/views/harmony/harmony_typography_provider.cc
index 939f5a5844dd0adedd803aac227a3fefd92ce7df..45efc5f97da9360dd5192b56325ff1b965fc34d8 100644
--- a/chrome/browser/ui/views/harmony/harmony_typography_provider.cc
+++ b/chrome/browser/ui/views/harmony/harmony_typography_provider.cc
@@ -66,6 +66,12 @@ SkColor HarmonyTypographyProvider::GetColor(
   // themed typography with a custom native theme. Typically just incognito
   // browser windows, when the native theme is NativeThemeDarkAura.
   if (foreground_color != SK_ColorBLACK) {
+    if (context == views::style::CONTEXT_TEXTFIELD) {
+      return theme.GetSystemColor(

[Peter Kasting, 2017/06/29 20:24:57]

Can we just return TypographyProvider::GetColor(...) here?  This looks like a
duplication of that code, and that seems like less of a maintenance risk.

[tapted, 2017/06/30 05:53:43]

I ended up tearing out this "what to do when we can't use Harmony" code into
some explicit functions (patchset 4), but those changes don't make as much sense
for this CL. Moved it to the CL that started all this
(https://codereview.chromium.org/2957263002/) and rebased on top. (I'll wait to
land this).


Longer explanation:

HarmonyTypographyProvider doesn't currently inherit from
DefaultTypographyProvider, so not without other changes. I've been hesitant to
add more layers of indirection. It's already super hard to answer questions like
"where did this color come from". We have explicitly set colors, implied
disabled/state colors, spec colors, native theme colors, common/aura theme
colors which all might get a say in what a color should be. (that's ignoring
Chrome themes for now).

I think "de-duplicating" things that happen to give the same result now, but
aren't really the same concept, is leading to the current set of problems in
NativeTheme -- everything is tangled and needs to be unwound to make simple
changes like "the text on buttons should be lighter".

The code here is effectively "when the user has an inverted color scheme how do
we draw text in textfields on a Harmony dialog". But the code in
DefaultTypographyProvider is just ~"what's a good default". And actually, the
decisions that Legacy/DefaultTypographyProvider makes for text are currently
wrong, at least for Windows 10's high contrast themes (but changes in the
"legacy" code I've been trying to do without side-effects).

For example, what usually ends up as the default text color is
"kColorId_LabelEnabledColor" and that uses COLOR_BTNTEXT on Windows. But the
::GetSysColor() documentation and that window that lets you preview the
high-contrast theme in Windows 10 suggest that COLOR_BTNTEXT should *only* be
used for buttons. In high contrast themes COLOR_BTNTEXT is usually white, but
all the other window text can be yellow or green.

I've fed this data into a function here, so we can get started on doing the
right things for high contrast themes. See what you think.

+          style == views::style::STYLE_DISABLED
+              ? ui::NativeTheme::kColorId_TextfieldReadOnlyColor
+              : ui::NativeTheme::kColorId_TextfieldDefaultColor);
+    }
     switch (style) {
       case views::style::STYLE_DISABLED:
       case STYLE_SECONDARY: