Issue metadata
Sign in to add a comment
|
Inactive frame colors are not consistent across normal/incognito/themed windows. |
||||||||||||||||||||||||
Issue descriptionVersion: 53.0.2785.101 OS: Windows 7 What steps will reproduce the problem? 1. Change Windows theme to Windows 7 Basic 2. Install and launch Chrome 53.0.2785.101 What is the expected output? Tab strip should be blue. What do you see instead? Observe the tab strip(not blue anymore), Please find some user feed back from Chrome release blog post from here : https://googlechromereleases.blogspot.com/2016/09/stable-channel-update-for-desktop.html Bisect range :https://chromium.googlesource.com/chromium/src/+log/53.0.2749.0..53.0.2750.0?pretty=fuller&n=10000 Suspecting : https://chromium.googlesource.com/chromium/src/+/2676e97c1a42b7898fbc09176ab94b59bf1c421d
,
Sep 10 2016
The active vs. inactive difference is #CCCCCC vs. #DCDCDC. See https://cs.chromium.org/chromium/src/chrome/browser/themes/theme_properties.cc?l=35 (and line 37). This was done in https://codereview.chromium.org/1798323002 to match ChromeOS, which I'm in agreement with in principle. That said, the different between these two states (on Win and CrOS) is pretty small. I think it would be nice to have at least a bit more contrast. The old Windows blue frame used #4274C9 vs. #A1B6E4, which is a lot of contrast. Mac currently uses #CCCCCC vs. #F6F6F6, which is noticeably more contrast than the CrOS pairing, at the cost of using something really close to white for the inactive case, which I know Sebastien is a huge fan of. Sebastien, can we change one or both these greys to get a bit more distinction here? Feel free to reassign to me for implementation.
,
Sep 10 2016
Not a blocker of any sort, not for merge to M-53.
,
Sep 13 2016
I am pretty attached to #CCCCCC which I think offers a good background against the inactive tabs and is also inline with the system. That's what Edge uses, which doesn't even bother making a distinction between active/inactive beyond shadow and frame stroke. When it comes to inactive we could push the color to #EBEBEB if that helps. But this is the type of issue where color change can only go so far.
,
Sep 13 2016
Is it weird that active frames are darker than inactive, while active tabs are lighter than inactive? In my machine at home I have the active frame color set to a lighter color than the inactive one and it reads a lot better to me. What if we used #CCCCCC for the active frame and something more like #888888 for the inactive frame?
,
Sep 13 2016
I agree, which is why chrome OS active/inactive are close, it's subtle, because we're following the Windows and Mac paradigm and because our tab system is based on a shade of grey. Side note: before, Chrome OS was light active, dark inactive (like you are proposing), which worked very well for tab contrast in all cases. Windows 10 default theming uses either all white for both states or color on active, white on inactive. Attached is what I see on my machine. Mac does it more elegantly as we dim the Core UI as well as the frame on inactive, making all element in the inactive window close to white. If we went for darker inactive (#888888) we would go against Windows paradigm, closer to the old chrome OS paradigm. My personal preference is to rely on shadowing and subtle hint, like what windows does for "modern" apps, where they don't even change the color, keeping the same UI contrast everywhere. I know you do not agree with me. For me, the color heuristic never worked, I often assume that the focus is on the wrong window, regardless of the platforms, or paradigm used.
,
Sep 13 2016
In both of those screenshots, the light-colored Windows looks active to me. The dark looks inactive. If we used to do this on CrOS anyway, and the tab contrast worked well, and something like Windows no longer even bothers to change the color natively, then I don't see what we are gaining by having the inactive window be lighter today. We're not following any kind of paradigm AFAICT. And on Windows we use the native frame on Win 10 anyway. So we're talking about affecting Windows users who are on e.g. Win 7 classic mode -- where Microsoft's new and IMO bad UI decisions have never been the norm. Also note that Mac frame colors are different in the implementation so even if we decide to change the code in this bug, it wouldn't affect Mac. So we can ignore Mac. Finally, even if "the color heuristic never worked" for you, it's not harmful to do it anyway. Sort of like, just because red/green colorblind folks require you to distinguish icons using more than just red/green color shifts does not mean that you shouldn't _also_ use color shifts to enhance the difference for non-colorblind people. And I definitely think that, for those of us for whom window frame colors are important, being forced to rely only on subtle cues, rather than subtle cues + color, is a usability loss. Given all this, I don't see any downside to using a darker, rather than lighter, color for inactive window frames.
,
Sep 13 2016
pkasting is correct here. The paradigm has always been light/lighter is active; you focus on the light. Dark/darker is inactive; you don't focus when there is no light.
,
Sep 14 2016
Well you ignore mac but it's still Chrome from a design perspective and I still compare all behaviors together because they impact UI decisions as a whole. The Windows 10 paradigm is dark/colored active , light inactive (if you color theme the OS) for apps built with for apps using the native frame, like Chrome, as far as I understand. Isn't the chrome classic mode available on Win10 as well and therefore going against native behavior if we go for darker ? I'm just trying to provide context. If we do not carry this theme on Windows 10 or if we do not care about the platform behavior (as in windows 10) here then yes, my arguments are mute. I'll let you make the call.
,
Sep 14 2016
,
Sep 14 2016
I don't really think of "color" versus "no color" as "dark" versus "light". It's just color versus its absence. And note that the 1 px window frame surround actually uses light-active, dark-inactive for Win 10 native, though this is less noticeable than the titlebar itself. Classic mode is gone on Win 10. Win 10 users will never see the opaque frame without using a theme, and themes set their own frame colors. I don't mean that Mac has no bearing on any design decision, but since we already don't use either the same colors or the same treatment (e.g. alpha) for active/inactive on Mac versus anywhere else, it seems like we've already decided divergence between it and other platforms is OK. I'm not worried that, if we use a dark inactive color on Win 7 classic and Chrome OS, we're going to introduce more divergence in a way that's worrisome. Given all this, I think using a dark inactive color makes sense. But I don't know what color would be best to use, assuming we stick with #CCCCCC for the active color. I proposed #888888 with only a couple minutes of testing, I would appreciate guidance on the ideal such color.
,
Sep 14 2016
I think #888888 would work fine. It marks enough of a difference for sure.
,
Sep 17 2016
Please use the system window colors on Windows instead of hard coding some gray values from another OS. The previous deep blue colors were annoyingly different from other system windows, but at least they were functional. The new light gray and slightly different light gray are NOT a clear indication of the active window. It's a huge step backwards in usability.
,
Sep 18 2016
Actually, that's a good point; the opaque frame on Windows is now programmatically rendered, so we can use the system frame colors when possible for it. Still want to change the default colors too.
,
Oct 24 2016
,
Oct 25 2016
,
Oct 26 2016
Continuing a discussion we were having over email, some people asked for a reference of all the different active/inactive frames we support on Windows. I made one here: https://docs.google.com/document/d/1ONm4V-oi8z_tHBwu77MZPjkfMu-qTXwnUSOzaWKkHyY This is relevant for bug 505013 . Whatever we decide to do here we should probably use for the default Windows 10 titlebar as well.
,
Oct 26 2016
Given Bret's screenshots, I think Alan's email proposal for what to do here is a reasonable starting point. Here's my attempt to summarize it:
For normal windows:
* If the user has set a specific active window frame color, use it. Otherwise, use #CCCCCC.
* If the user has set a specific inactive window frame color, use it. Otherwise, use color_utils::AlphaBlend(active_color, SK_ColorWHITE, 0x33) (i.e. 20% active color, 80% white). This means that for very light frame colors/images, the active/inactive contrast will be low. We plan to just accept this. (The contrast should be good enough in the default #CCCCCC case.)
* For custom-themed windows, use the theme colors and images as appropriate. If a theme does not specify various colors, compute them from the ones it does specify using the logic above. To compute inactive frame images, alpha-blend a white layer with the active images.
For incognito windows, use the logic above, except:
* Use #282B2D as the default active frame color.
* Alpha-blend with the params flipped: color_utils::AlphaBlend(SK_ColorWHITE, active_color, 0x33) (i.e. 20% white, 80% active color). This is because the 20% active/80% white behavior is too stark.
Alan, did I get this correct? In particular, how you computed the incognito inactive color.
My concern with this is that incognito windows are not the only windows that have really dark frames/tabs/etc. I wonder if instead of making this toggle based on incognito, it should toggle based on frame, active tab, and/or inactive tab color. For example, "if the frame color is dark, use the flipped alpha blend params". ("Is dark" here would probably mean "contrasts less with black than white", but we could tune this threshold some other way if desired.)
,
Oct 27 2016
I prototyped this, see attached screenshots.
,
Oct 27 2016
The user colors are the lightest and darkest colors I could find on the accent color palette. Since the other windows are just going white when inactive, even a large contrast like with the dark looks okay in context. For what it's worth, I think using the default blend on incognito looks fine as well (see attached for example).
,
Oct 27 2016
I'm OK with that treatment of dark/incognito windows if Alan is. The most extreme version for the contrast case would be a black theme with black toolbar/tabstrip. There are some of those in the webstore, is your prototype capable of showing what one would look like?
,
Oct 28 2016
Here's what it would look like. You can only actually get here by editing the registry though. We don't have to worry about themes; when I hooked up themes to this everything Just Worked. They can specify an inactive frame image and in practice it seems like they all do.
,
Oct 28 2016
The theme case is precisely the case I wanted to see -- a theme with a black frame and black toolbar + tabstrip. I wanted to know how bad the contrast of the light frame would look in that case. (BTW, I wouldn't assume that all themes that specify an active frame image specify an inactive one.)
,
Oct 28 2016
That inactive frame is 0x808080, which would be 50% white instead of 80%. Did you implement something different than comment 22?
,
Oct 28 2016
No, it's the same code I used to generate #26. Maybe there's something I missed about themes, let me investigate.
,
Oct 28 2016
That's really contrasty. OTOH, Windows' white titlebars are inherently really contrasty. So its kinda native. I'll shut up and wait for Alan's thoughts.
,
Oct 28 2016
In order for this scenario in #31 to actually happen though the theme would have to not specify any frame colors, and the user would have to modify the registry to give themselves a black titlebar. So it's not very likely. Most of the time you would get something more like #28, where themes use a less contrasting blend by default and then that can be overridden.
,
Oct 28 2016
The reason I suggested testing this case is because my proposal is that we generate inactive frame images (which I think most themes probably don't ship) by using the same "80% white blend atop active frame image" algorithm as in the unthemed case. So I think it would actually be pretty common that you'd get themes that would look like this.
,
Oct 28 2016
I took a more careful look through the theme code. We generate inactive frame images by HSL shifting using kDefaultTintFrameInactive. I'm not familiar with the HSL shift algorithm but empirically it results in a 50% white blend (with a black image at least). Both the inactive frame image and default inactive tint are overridable by the theme. In practice, not a single theme I tested did so. So changing the default theme tint is sorta orthogonal to what we want to change here, and I don't think it's a good idea. Themes are tuned to the defaults, and they already have the ability to change it if they don't like it. There are actually a bunch of default tints, e.g. for incognito mode, so if we REALLY want to rethink default theme tints we should rethink them all together. Plus changing it would affect every platform. Though I'm still not clear on what colors we want to apply to non-Windows platforms.
,
Oct 28 2016
Can you say more about why you think changing kDefaultTintFrameInactive is orthogonal to this? It seems to me like that's precisely what we want to do.
The HSL shift for "blend with 80% white" would be {-1, -1, 0.9}.
If a theme overrides the image or the tint, then that would override our defaults. But if they don't, we're basically saying we're changing things so that inactive frames are lighter.
(I don't know about whether the incognito tints there are applied successively or not, so I'm not sure how to propose modifying them, but we'd want to do that too.)
I'm still assuming we want to make this change across platforms.
,
Oct 28 2016
It's orthogonal because the effort here is "make the Windows 10 titlebar not white" and "increase contrast on the opaque frame." Not "globally unify frame colors." It's good we're keeping the latter in mind when making these decisions, but themes look fine right now and trying to rebalance their default tints is getting off into the weeds. Though if there is an obvious conclusion about them then I suppose I don't mind implementing it. But I'd also need to know if we wanted to roll it out along with custom titlebar, immediately, along with a separate effort, or variably depending on the platform. To your parenthetical, the tints are not layered. So e.g. incognito/inactive tint is applied directly to the normal/active image.
,
Oct 28 2016
The "make win 10 not white" etc. work kinda spilled into this bug to be solved as part of it, but the intent of this bug is to do the broader thing. That's why I had it assigned to me and didn't just pawn it off :) More to the point, if we fiddle with how all the unthemed colors get calculated, we _should_ fiddle with themes, so users don't have jarringly different experiences just because they installed a theme and now the whole paradigm is different. And we already knew we wanted to change every (non-Mac at least) platform in unison, which is part of why Evan and I unified the CrOS and views frame colors during the MD top chrome work. That also fits the Harmony goals. So I think it's consonant with our recent history, immediate future direction, and plausible best behavior to do things in a unified way. As to rollout, I'd just land all this stuff at once rather than stage it by platform. I'd do it in advance of the custom titlebar being on by default.
,
Nov 29 2016
It seems like Bret is owning this, practically speaking.
,
Dec 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5afcb514af8ccd26ef17078957483f1be72bc592 commit 5afcb514af8ccd26ef17078957483f1be72bc592 Author: bsep <bsep@chromium.org> Date: Fri Dec 16 05:04:32 2016 Change default frame colors. Change custom titlebar colors on Windows. Default frame colors are changed so that inactive frames are always a blend of 80% white/20% active color to increase contrast. * The normal/inactive frame is changed to #F6F6F6 on all platforms. (OSX was already at this color.) * The incognito/inactive frame is changed to #D4D5D5 on all platforms except OSX. * The tints applied to theme images are changed to match the new lightness ratio as well. Inactive tint is changed to 80% lightness. Incognito/inactive is changed to be 74% lightness, which approximates blending 80% white on top of the active tint's 30% black. Also increased saturation change of incognito/inactive to match incognito/active. Windows will now pick up the user colors specified by the system and use them when custom drawing the titlebar. It will never draw the titlebar white unless the user explicitly specifies that color. It uses an 80% white/20% active blend to calculate inactive frame colors if the user has no frame color specified, just like above. BUG= 505013 , 645682 Review-Url: https://codereview.chromium.org/2541873004 Cr-Commit-Position: refs/heads/master@{#439030} [modify] https://crrev.com/5afcb514af8ccd26ef17078957483f1be72bc592/chrome/browser/themes/browser_theme_pack.cc [modify] https://crrev.com/5afcb514af8ccd26ef17078957483f1be72bc592/chrome/browser/themes/theme_properties.cc [modify] https://crrev.com/5afcb514af8ccd26ef17078957483f1be72bc592/chrome/browser/themes/theme_service_win.cc [modify] https://crrev.com/5afcb514af8ccd26ef17078957483f1be72bc592/chrome/browser/themes/theme_service_win.h [modify] https://crrev.com/5afcb514af8ccd26ef17078957483f1be72bc592/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
,
Dec 20 2016
OSX incognito mode is the only place that doesn't conform to what we've decided here and shrike@ told me to leave it be. So unless we want to revise the chosen colors I believe this is finished.
,
Feb 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/af5bd1316ab3fd3054d08471c0a25b4b7c66cf9c commit af5bd1316ab3fd3054d08471c0a25b4b7c66cf9c Author: bsep <bsep@chromium.org> Date: Tue Feb 07 22:40:42 2017 Revert incognito and theme inactive color changes. Partial revert of crrev.com/2541873004. We're not happy with the colors and we don't want to ship them in 57. But we're keeping the default non-incognito/inactive color change to #F5F5F5 because it dramatically increases contrast with the active frame. BUG= 645682 , 677172 Review-Url: https://codereview.chromium.org/2663363002 Cr-Commit-Position: refs/heads/master@{#448752} [modify] https://crrev.com/af5bd1316ab3fd3054d08471c0a25b4b7c66cf9c/chrome/browser/themes/browser_theme_pack.cc [modify] https://crrev.com/af5bd1316ab3fd3054d08471c0a25b4b7c66cf9c/chrome/browser/themes/theme_properties.cc
,
Feb 7 2017
Reopening. We weren't happy with the result so I reverted all changes except the one to the normal/inactive frame color. That should address the issue raised in the OP. But since this bug turned into a more general fixing of frame colors I'm explicitly re-purposing it. The main problem was that the contrast was glaringly high with a dark color scheme, like with incognito mode or a dark theme. There is an idea to adjust the contrast dynamically based on the active color, and that's my list to make a prototype for.
,
Feb 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d542e5990f46859423784528739ea9b5e406b3c8 commit d542e5990f46859423784528739ea9b5e406b3c8 Author: Bret Sepulveda <bsep@chromium.org> Date: Tue Feb 21 23:54:35 2017 Revert incognito and theme inactive color changes. Partial revert of crrev.com/2541873004. We're not happy with the colors and we don't want to ship them in 57. But we're keeping the default non-incognito/inactive color change to #F5F5F5 because it dramatically increases contrast with the active frame. TBR=estade@chromium.org BUG= 645682 , 677172 Review-Url: https://codereview.chromium.org/2663363002 Cr-Commit-Position: refs/heads/master@{#448752} (cherry picked from commit af5bd1316ab3fd3054d08471c0a25b4b7c66cf9c) Review-Url: https://codereview.chromium.org/2712583002 . Cr-Commit-Position: refs/branch-heads/2987@{#630} Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943} [modify] https://crrev.com/d542e5990f46859423784528739ea9b5e406b3c8/chrome/browser/themes/browser_theme_pack.cc [modify] https://crrev.com/d542e5990f46859423784528739ea9b5e406b3c8/chrome/browser/themes/theme_properties.cc
,
Feb 22 2017
There was no merge request for CL listed at #44. Please revert the merge from M57 branch 2987 as we're getting closer to M57 Stable promotion. Issue listed here is P2 and exists since 53. So this can wait until M58 goes to Stable. Thank you.
,
Feb 22 2017
The merge request was approved under issue 677172 . The original CL was related to both issues. Sorry for the confusion!
,
Feb 22 2017
Thank you bsep@ for clarification.
,
Feb 22 2017
Rechecked this issue on Windows 7 for chrome version 57.0.2987.74 by Changing Windows theme to Windows 7 Basic, Attached are the screenshots generated for the same. @bsep: Request you to please take a look into it and confirm if this is intended. Thanks.!
,
Feb 22 2017
,
Feb 22 2017
Yes, that's intended.
,
Feb 23 2017
Thanks for the update. Adding TE-Verified labels.
,
Sep 18
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by gov...@chromium.org
, Sep 10 2016