Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/938475d078e1326dc517c4202e58531886ac777f..7d0bf8fed9ec38daeb120d7c68466b0666d21cd8?pretty=fuller&n=100

Suspecting: r390760

Note: Above issue is not seen on Windows and Linux OS.

Adding RB label as this is a recent regression.

Not sure I fully understand the bug. Incognito mode in Material Design is a dark style, with white toolbar icons, black-background omnibox dropdown, etc. Themes that are considered dark also use this style for toolbar icons and the omnibox dropdown. Re: the omnibox in particular if you have a dark theme, which typically has a dark NTP page, a white-backgrounded dropdown can be pretty jarring.

Filing as works as intended. Feel free to reopen if I'm not fully understanding the problem (and if so, please elaborate).

It seems strange that in the screenshot, the omnibox itself is dark-on-light, but the dropdown is light-on-dark.  That combination doesn't match either the light or dark color scheme on Windows.

When you have a dark theme the Omnibox textfield remains white but everything else is like Incognito mode. At one point I made the Omnibox textfield dark also for dark themes but during testing I noticed that that a black omnibox textfield sometimes clashed with a black omnibox (none of the themes were designed with the assumption of a black omnibox).

What does Windows do with the omnibox for dark themes, and how does it decide if a theme is dark or not?

Windows does not consider any theme "dark" in the sense of triggering any of the incognito styling.  The incognito styling is only used for incognito in the normal theme, for consistency with previous Chrome versions, and I think that's the correct behavior.

So I would remove the code on Mac that tried to detect "dark" themes and plug in parts of the incognito color scheme.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Using Incognito styling for dark themes was added at the request of UX (specifically, sgabriel@).

Then why aren't we doing it on Windows? The answer to this needs to be the same across platforms.

Using the incognito style for some themes causes color compat problems on those themes; that goes double when we only use some and not all the incognito colors.

I'm almost certain this should be reverted.  ->sgabriel to get his sign-off.

Incognito style *must* be used with dark themes in Material Design, otherwise the shade-of-gray toolbar icons in normal mode will be invisible on toolbars with dark backgrounds!

sgabriel@ has already signed off on this (he requested it in the first place). I guess you are asking him to confirm to you that this is what we should be doing.

No, I'm saying the original decision was wrong and needs to be reversed.

I don't know what you mean by "the shade-of-gray toolbar icons in normal mode will be invisible on toolbars with dark backgrounds".  If there is a real problem here, it should be impacting Windows today.  But attached is a sample screenshot with a dark theme, looking fine.

Let me know what specifically I should test to repro, or not, the problem you're concerned about.  Either we will need to fix it on Windows, or whatever we're doing there is what we should be doing on Mac as well.

Deleted: Untitled.png 9.8 KB

	Untitled.png 9.8 KB View Download

For clarity: there are codepaths in views that do things differently for light or dark colors in general, e.g. DeriveDefaultIconColor() will behave differently for those two.  In that sense, there are certain pieces of functionality that take effect for incognito because it is dark, which also take effect for other dark themes.

But this is separate from using parts of the incognito theme or any incognito-specific colors for non-incognito.  That's what I was objecting to.

And the omnibox dropdown specifically is a case where the colors should not be based on whether the theme is dark, especially when the omnibox itself is not so based.

> And the omnibox dropdown specifically is a case where the colors should not be based on whether the theme is dark, especially when the omnibox itself is not so based.

Here we do not share the same opinion. A white-backgrounded omnibox dropdown is pretty jarring when placed over a dark theme NTP background. But sgabriel@ should make the final decision.

Deleted: DarkThemeNormalStyle.png 759 KB

	DarkThemeNormalStyle.png 759 KB View Download

Deleted: DarkThemeIncongitoStyle.png 756 KB

	DarkThemeIncongitoStyle.png 756 KB View Download

Having a white edit atop a dark background is worse.  The two should only ever change in sync.

Here's the initial logic:

The omnibox dropdown styling should be bound the the state in which Chrome is, regardless of its theming.

This mean that even if the theme is dark, it should be white in normal mode and black in incognito mode. This comes from the need of differentiation between the 2 modes.

Sorry if this wasn't clear. 

I think this corresponds to what Peter is saying correct ?

Not quite.

On Windows, we don't use a dark omnibox dropdown with a light omnibox even for a custom theme's incognito window.  The behavior of our colors w.r.t. incognito windows is unclear to me; +cc estade to comment on that.

It would be a little odd IMO to distinguish the two based on the dropdown, which isn't normally visible, and whose entries are going to behave the same way when selected as they would in a regular incognito window.

For the initial logic, I didn't want themes to completely bypass incognito mode. There was a concern from UX that it was hard to distinguish normal from incognito, hence the dark mode as well as the different omnibox dropdown.

The white omnibox is correct I think as it should because theme can have image, not only flat colors so it's better for visibility since incognito omnibox is transparent.

sgabriel@ - Incognito vs. non-Incongnito is already differentiated via the presence or absence of the Incognito Guy icon, but if you want to use the dropdown to also indicate the mode, that is your call.

To be clear, does what you say about the dropdown color also apply to the omnibox textfield background color, i.e. always white in normal mode and always black in Incognito mode?

The incognito omnibox isn't transparent on Windows, it's #626262.  So that shouldn't be a concern there.

It still doesn't make sense to me to change the dropdown without changing the omnibox, without looking at the NTP background color, and without the actual meaning of the dropdown changing.  If we just wanted to indicate incognito, we'd change the omnibox and the background (and if that means making the omnibox non-transparent on Mac, by all means do so).  If we wanted to match the theme, we'd change both in sync with the theme toolbar color, or with the NTP background color.  (And we're definitely not changing the dropdown to indicate a functional change, since its function is still the same.)

The current situation on Mac doesn't match any of those, and neither does what you're talking about doing.

I asked Evan to comment here because we do various things with all the theme colors in incognito mode, where we seem to e.g. darken the frame colors/images even for custom themes.  I think we should either say that it makes sense for the omnibox and its dropdown to be dark in incognito like it is without a custom theme; say that we're not going to touch these at all in custom themes, incognito or no, because our other color tweaks are good enough; or say we'll make a decision between those two based on the darkness of some color or set of colors in the theme.  But when we don't change them in sync, it's harder to rapidly scan downwards visually across the color inversion, and when we don't make the same changes for custom themes as non-custom, it's confusing.

Makes sense. Let's keep them in sync with each other, independentof theme color.

Meaning that a Dark themed Chrome will have white textfield + white dropdown in normal, black textfield + black dropdown in incognito, treating omnibox + dropdown as signifier of state, not brightness of theme. 

Doest that makes sense from both implementation standpoint?

Works for me.

That means Windows needs to change so that incognito custom themes get dark omnibox and background, and Mac needs to change so that the omnibox and dropdown colors are in sync with each other and toggled off the incognito state rather than theme color.

We should perhaps split this into Mac- and views-specific bugs?  I'll assign this to Evan for now for the views part (but Evan, dump back to me if need be) and leave what to do about Mac in Jayson's hands.

sgabriel@ - I just want to add that I disagree with pkasting@'s opinion: making the Omnibox dark to match the dropdown background is not the correct thing to do. *All* custom themes were designed around a white Omnibox textfield. There will be some that won't look right with a dark rectangular blob now in the middle of the toolbar (I won't bother trying to screenshot any if the decision has been made, but this is what I discovered while implementing the MD Omnibox UI).

I wouldn't consider anything set in stone; if you can give an example of a theme which looks significantly worse maybe we can do something different.

I can't actually remember why we decided not to apply the dark theming to custom themed incognito windows, but it was done intentionally: https://bugs.chromium.org/p/chromium/issues/detail?id=581559 (my guess is because light themes aren't darkened enough in incognito to avoid this looking out of place)

What about the find in page bar? Should that also be darkened for custom themes?

Huh, I just noticed that in an unthemed incognito window the find bar gets darkened but things like the bookmark bubble don't.  Seems like those should ideally be in sync now that we're styling the find bar similarly to a bubble.  Maybe that's part of your secondary UI work?

Can themes set the color that affects the find bar?

Kicking this over to sgabriel again to make sure he's OK with the concerns raised in comments 22 and 24.

> Maybe that's part of your secondary UI work?

plans can change, but no, it is intentional that the dark styling only applies to the toolbar and fip bar.

> Can themes set the color that affects the find bar?

No, it matches the textfield bg, which is part of the native theme.

re #22: I understand. There are two things conflicting here, making our UI react as good as possible with a theme and making incognito more obvious. I'm always more inclined to decide in favor of UX concern rather than theme concerns, as themes are not something we can really control. Theme should be as good as we can get them for normal, not incognito, it is not something we want people to live in anyway.

re #24: fip should keep its current behavior, white for normal, black in incognito, regardless of theme. 

Bookmark bubble or any bubble for that matter should be themed, fip is an exception.

> Bookmark bubble or any bubble for that matter should be themed, fip is an exception.

I think you forgot a "not" here?

What's the rationale on leaving the bookmark bubble white in incognito when all the UI around it has become dark?

If we made the bookmark bubble dark, wouldn't we need to make all bubbles dark? If we start making all bubbles dark for incognito, I think it will wind up being a lot of extra work both on a design and implementation side for little gain. The main window indicates the incognito state pretty unambiguously so changing the bubbles as well doesn't seem necessary.

Yes, my assumption was that we make all native UI dark.  If the frame, tabstrip, toolbar, find bar, New Tab page, and download shelf are all already dark, that covers like 95% of what people will ever see, so having things like the bookmark bubble white feels glaring.

How many places in the code would actually have to change?  It seems like just changing a few color constants ought to fix the majority of these, shouldn't it?

> If the frame, tabstrip, toolbar, find bar, New Tab page, and download shelf are all already dark, that covers like 95% of what people will ever see

exactly. And the last 5% of what people would see is a long tail of a bajillion bubbles that will not just automatically work (even if they *mostly* work because we change the bg and label color). I don't think the effort to reward makes this worthwhile (phrased another way: we're never going to spend enough time on this to ensure a good level of polish for every bubble in incognito). Currently, dark custom themes have a white bookmark bubble and I've never heard the complaint that it's glaring.

Re #28 yes I forgot the not :)

no bubble or dialog should be black. Fip is an exception because I think it uses the same code as the omnibox if I remember correctly.

To summarize:

* The plan at the moment is to always use dark omnibox/dropdown in incognito, and always use the normal ones outside incognito.  This requires changes on both views and Mac.

* Jayson may have concerns about this that UI Review should take a look at before we move forward, so we're waiting to hear on that.

* The most plausible alternate behavior from the above plan is what views does today, where we always use the normal omnibox/dropdown for themes, and only use the dark ones in non-themed incognito mode.  This is not less clear about what's incognito than the pre-MD world, and minimizes theme color compat risks.

I exchanged e-mail with sgabriel@ about this, and we are both happy proceeding with the the alternative behavior described in # 35:

Do what views does today, where we always use the normal omnibox/dropdown for themes, and only use the dark ones in non-themed incognito mode.  This is not less clear about what's incognito than the pre-MD world, and minimizes theme color compat risks.

Cool, changing to be just about the Mac changes then.  Feel free to reassign if you won't be the one doing the work.

(Oh, or you can dupe against  bug 621740  I guess)

 Issue 621740  has been merged into this issue.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

this message is simply here to tickle this bug as I'm going the old omnibox bug triage sweep.  It looks like the plan is posted in comments #35-37.