This is related I think to Peter's change on the stroking for very dark themes. Incognito getting darker when inactive activates the white stroking. I hope this can be fixed in this particular case because it looks bad.

A dark stroke against the top background color would be invisible, since that color is already nearly black.  We would only do that if the code was simply "always use a dark stroke".

I did my best to come up with a dynamic stroke color that tries to achieve at least some contrast with both tab and background, but without using a light stroke for the "default" incognito active/inactive color combos (even though the contrast there is already very low), and without jumping straight to a blinding pure white in dark cases like this.  Not familiar enough with Linux to know whether the inactive background color here is itself correct or if we should be selecting something closer to what happens on Windows.  However, if it's correct, then I stand by the choice of stroke colors here, although I'll certainly listen if someone suggests an alternate to https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/themes/theme_service.cc&sq=package:chromium&type=cs&l=619&rcl=1459524713 .

I assume we cannot special case incognito, can we ? 

What would happen if the tabs were white ? Would the code still display white strokes even though we'd need them to be black ? 

Could stroke color change be based on foreground/frame contrast rather than frame color only? 

For your first question, we can special-case anything we want, but we need to know what rules we want to play by.  To me what makes sense is saying that the stroke needs to have at least some contrast against tab and frame at all times, not just in non-incognito windows.

For your other questions, the algorithm already looks at both the active tab color and the frame color and picks a shade that will contrast (at least a little) with both.  The stroke color is semitransparent and painted atop the frame color; if the tab were white and the frame were black, the stroke color would have to be white (since a black stroke wouldn't darken a black frame), but it would be of fairly low opacity, so the resulting blend would have more contrast with the tab color than with the frame color.

I'd be in favor of special casing this specifically as it touches our normal incognito theming.

For the point about the rules. Seeing the stroke in the design is not a requirement, it could very well be invisible if the foreground/background tab and frame color were contrasty enough so we don't need a stroke at all. The stroke is here to help contrast.

In the case at hand, the code switches the stroke to white (in inactive) where the contrast is actually better than when the stroke is black (in active).

Seeing the tabs without a visible stroke can look bad, especially when there's more than just one tab, because in that case it looks as if the background tabs are just floating blocks that have been chopped off the toolbar.  I tested this originally and while it works OK for a single tab it just didn't look good in the multi-tab case.  So I'm not keen to move to an algorithm that can have that outcome.

If we consider this theme to be part of the "normal" theme, why is it using the particular background color it's using?  That's not the standard inactive incognito window color.  Is Linux supposed to use this color?  If not, fixing that would fix this issue without modifying the algorithm.

My worry here was that inactive window seems to be more prominent and demanding attention and I thought it should be other way around.

You are righ :) My point is more stroke can be subtle. 
I think your implementation is sound. 

To your second point, inactive frame in Chrome OS have a different theme like on OSX. Windows does that natively with the color/white change. In this case I use a color that might be too dark. We can certainly modify that.

Base on your code, are you able guess the minimal color the frame would have to be NOT to switch to the white stroke ? We could then simply make a color change.

Hold on, Linux may actually be using the specified color here, which makes me wonder what I was seeing on Windows (and I did test in a scenario where I was not using the Win 10 native frame colors).  Give me a bit to build Windows and debug this some...

At least on Win 7, I'm seeing the same issue as in this bug.  I'll need to figure out what was different about my testing at home (or if I was smoking crack).

The "active incognito window" has pretty close to the minimum contrast ratio between the frame color and a darkened "frame + stroke" color.  One way to prevent the effect here would be to use a lighter color for inactive incognito window frames rather than a darker one.  I don't know if there are any good design options in that direction.

OK, I was smoking crack before.  I don't think I paid enough attention to inactive incognito windows.

I notice that for normal windows, we already lighten (instead of darken) the frame when it's inactive.  I tried doing that for inactive incognito windows, as I proposed in comment 10, and I think it looks pretty good.  Attached are screenshots of the current active incognito window and the proposed inactive window, as well as an option where we keep the current inactive frame color and make the tab outline black.  To me, the "proposed" inactive state looks more like an "inactive window" when you toggle between it and the active window than does the "designed" inactive state.

Sebastien, would you be OK with this idea?  Here are some colors:
Current active: #282B2D
Current inactive: #141719
Proposed inactive: #383B3D

I'm by no means wedded to this color, so if you have a better suggestion I'm happy to take it.

Deleted: active.png 32.9 KB

	active.png 32.9 KB View Download

Deleted: proposed_inactive.png 32.9 KB

	proposed_inactive.png 32.9 KB View Download

Deleted: designed_inactive.png 33.0 KB

	designed_inactive.png 33.0 KB View Download

Thanks for looking into this. I am very happy with this solution as well as the color you picked for the frame. Let's do that :)

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

commit f549e90f4bf57b261f0f9db9971dc0193b433358
Author: pkasting <pkasting@chromium.org>
Date: Thu Apr 07 00:01:33 2016

Lighten incognito frame when inactive, instead of darkening it.

BUG= 599952 
TEST=Run Chrome with --top-chrome-md=material on Linux, using the Classic theme.  Open an incognito window and then deactivate it.  The frame should lighten and the outlines around tabs should stay dark.

Review URL: https://codereview.chromium.org/1862923002

Cr-Commit-Position: refs/heads/master@{#385593}

[modify] https://crrev.com/f549e90f4bf57b261f0f9db9971dc0193b433358/chrome/browser/themes/theme_properties.cc

This will, I believe, affect ChromeOS as well, and thus should be a merge candidate for M-50.

Branch owners, the change here is very safe, just a change of a color constant.

Merge approved for M50 (branch 2661). Pls go ahead merge.

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

commit 6217e3d464614465e46080937f99e9fbf1dc08df
Author: Peter Kasting <pkasting@chromium.org>
Date: Thu Apr 07 22:59:10 2016

Lighten incognito frame when inactive, instead of darkening it.

BUG= 599952 
TEST=Run Chrome with --top-chrome-md=material on Linux, using the Classic theme.  Open an incognito window and then deactivate it.  The frame should lighten and the outlines around tabs should stay dark.

Review URL: https://codereview.chromium.org/1862923002

Cr-Commit-Position: refs/heads/master@{#385593}
(cherry picked from commit f549e90f4bf57b261f0f9db9971dc0193b433358)

Review URL: https://codereview.chromium.org/1867173002 .

Cr-Commit-Position: refs/branch-heads/2661@{#515}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/6217e3d464614465e46080937f99e9fbf1dc08df/chrome/browser/themes/theme_properties.cc

Verified the issue on Ubuntu 14.04 and Win 7 using beta # 50.0.2661.75 and its working fine.Please find the screen cast for the same.

Deleted: 599952_Apr_13.ogv 4.4 MB

599952_Apr_13.ogv 4.4 MB Download