Evan, could you take a look?

do you have --secondary-ui-md enabled? From reading the code it looks like that would break this. The icon color keys off the text color (so it works well with themes, incognito, etc.) and the text color is changed to #333 with that flag passed.

it occurs to me you'd probably see a different color of omnibox text too (for the domain part of the URL)

I do have it enabled.

is the omnibox text supposed to be changing color?

nothing is supposed to change color.

Well, this is a bit unfortunate because before we could use the textfield default color (as provided by the native theme) and now we have to add a new color just for the omnibox text. >:[

Having omnibox work well with themes SGTM but for the default theme case, it should not change.

it seems that Alan may have decided to change the text color for textfields back to black, but as far as I can tell the mocks don't reflect that yet. See attached (text next to "textfield").

Alan, could you clarify?

Deleted: SPEC-secondary-UI-06-dropdown-texfields.png 188 KB

	SPEC-secondary-UI-06-dropdown-texfields.png 188 KB View Download

c#2 is checking to see if the Omnibox text color change is related to the --secondary-ui-md flag. That flag turns on Harmony, which is secondary UI. The Omnibox is primary UI - it should not be directly coupled to anything the secondary UI is doing. Although the Omnibox and secondary UI textfields both accept typed input, the Omnibox is much more than a simple input textfield.

I believe where you are going in c#10 is that the Omnibox should be drawing the domain portion in black, and it looks like secondary UI textfields may have been changed to draw their text in black, and so the Omnibox and secondary UI textfields can continue using the same text color. The two should not remain connected in this way.

I think design was unaware that both surfaces were using native theme color as described in #8. Color management is a bit opaque on the design side so more transparency there would be good, especially when we know that the a surface that wasn't supposed to be #333 will change color all of a sudden.

I'm not sure I understand how the icons got re-themed though. Why are omnibox icons linked to omnibox text color while regular icons stayed the proper color ?

The omnibox icons key off of the omnibox text color, which allows them to be visible on the location bar's bg no matter what the omnibox text color is (which can change based on NativeTheme, e.g. incognito or Gtk theme mode).

The toolbar icons are on top of the toolbar itself, which changes based on the browser theme (i.e. those things you get from the chrome web store). That's why the machinery for picking the colors is different between the two types of icons, although it comes out to 5a5a5a in both cases for the default theme.

Thanks for explaining :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/49f11a61a9f208a5d971edb69df03edf21f9f06a

commit 49f11a61a9f208a5d971edb69df03edf21f9f06a
Author: estade <estade@chromium.org>
Date: Sat Oct 01 01:49:15 2016

Update "primary" text color for Harmony.

Changed back to black.

BUG= 651492 

Review-Url: https://codereview.chromium.org/2374253011
Cr-Commit-Position: refs/heads/master@{#422261}

[modify] https://crrev.com/49f11a61a9f208a5d971edb69df03edf21f9f06a/ui/native_theme/common_theme.cc

icons should be back to 5a5a5a