Thanks for filing the issue...

As per comment #0, it seems to be a feature request. Hence, marking it as untriaged for further inputs from Dev team.

Thanks..!

Hi Phanindra,
Are you certain it's not also a bug, ie. Chrome theme behaviour not working as originally intended?

Also, what does "untriaged for further inputs" mean? (Just curious)

I think your problems (3) and (4) are reiterations of problems (1) and (2).  Problem (2) looks like a real bug to me, but distinct from problem (1); maybe file that separately?  Problem (1) seems like a legitimate feature request, but one I'm not sure whether we should implement.  Right now there's a limit to what colors people can set differently in incognito windows, inactive windows, etc.  If we want to do this, why not let every color vary based on each input?  ...which would imply we need a different color selection mechanism, e.g. one more like CSS selectors, instead of unique identifiers with things like "_incognito" and "_inactive" tacked on.

You're right, (3) and (4) are reiterations of (1) and (2). :)

I assumed (1) and (2) were related, or had the same root cause, but if you think they are different enough, then I can create (2) as a separate issue.

To me it's not clear if (1) is only a feature request or also a bug (ie. behaviour not working as originally intended). It feels a bit like a bug to me.

You're right that there's a limit to the colours a theme can set in Incognito mode, but maybe that's what needs to change? You'd only need to add three additional values to the theme to resolve this issue, as follows:

* toolbar_incognito
* tab_text_incognito
* bookmark_text_incognito

Everything else needed to keep the Incognito colour scheme distinct from the regular colour scheme is already provided!

The problem currently is that without any theme applied, Incognito mode has its own distinct colour scheme, but the theming mechanism only allows a subset of the Incognito window elements to be themed, and the remaining Incognito elements (ie. the three I've listed above) inherit the colours from the regular window, which gives unexpected and undesired results.

I don't see the need to use CSS or reinvent the wheel. Just add the three elements above, problem solved! ;)

I guess I'm sort of morphing into two distinct issues:

(1) Provide the ability to specify a separate incognito color for at least some additional colors (toolbar background and various foregrounds).  Note that to maintain backward compatibility, and since "change both normal and incognito" is usually what authors explicitly want, we wouldn't just make the non-incognito variants only apply to non-incognito windows; instead we'd add an incognito-specific variant, and if you want incognito to do something different than normal, you'd need to manually set that.
(2) Don't override default colors unless a theme explicitly sets them.  In particular, don't override incognito ones to look like normal ones when the normal ones themselves were never set.

I consider (1) this bug and (2) another bug -- note that it looks similar to the issue about not overriding the frame color when a theme doesn't set it.

There's perhaps a variant of (2) that would be a feature request, to have some sort of explicit "use default value" color token.  So for example you could override the toolbar color to be red in a normal window, and then mark the incognito toolbar as "use default color".  This would help address maintainability problems with (1).

You're right, (2) is clearly separate. I'll go ahead and create (2) as a new issue then.

I think what you've written in your paragraph under (1) in Comment 6 is in line with my suggestion in Comment 5, right? In other words, adding these three new theme values would basically achieve what you're suggesting:

* toolbar_incognito
* tab_text_incognito
* bookmark_text_incognito

So if a theme doesn't include these three new values, then the existing behaviour still applies. That keeps existing themes from breaking.

Okay, new issue created for (2) here: Bug 915802