New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 669682 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 307091



Sign in to add a comment

Overlay scrollbar stroke too strong when hovered

Project Member Reported by bokan@chromium.org, Nov 29 2016

Issue description

Version: 57.0.2936.0
OS: ChromeOS

The alpha used to draw the scrollbar when hovered is 0.5:

https://cs.chromium.org/chromium/src/ui/native_theme/native_theme_aura.cc?q=native_theme_aura&sq=package:chromium&l=35

We should either increase the alpha (making it more opaque) or make the stroke an off white color to make it less strong.

 

Comment 1 by bokan@chromium.org, Nov 29 2016

Labels: OS-Chrome

Comment 2 by bokan@chromium.org, Nov 29 2016

Owner: sahel@chromium.org
Status: Assigned (was: Available)
Sahel, I got the wording above backwards, we should *decrease* the alpha and make it more transparent. I think we want to decrease the alpha just on the stroke: https://cs.chromium.org/chromium/src/ui/native_theme/native_theme_aura.cc?q=NativeThemeAura&sq=package:chromium&l=220

Try a few different values, take screen shots and post them here so we can compare (http://material.io is a good one as it has dark background sections where the scrollbar outline is clearly visible). I've attached what it looks like today.
Screenshot from 2016-11-29 17:10:18.png
2.9 KB View Download

Comment 3 by sahel@chromium.org, Dec 14 2016

Currently these alpha values are used to paint both the thumb and its stroke.
kOverlayScrollbarAlphaNormal = 0x4D;
kOverlayScrollbarAlphaHovered = 0x80;

I added a new constant for stroke transparency while hovered.
kOverlayStrokeAlphaHovered

Attached are pictures of kOverlayStrokeAlphaHovered = 0x58,0x60,0x68,0x70,0x78,0x80(the current value).

Alpha values less that 0x58 didn't have any meaningful differences with 0x4D.(Normal and hovered states had almost identical strokes)
0x58.png
89.3 KB View Download
0x60.png
68.9 KB View Download
0x68.png
84.4 KB View Download
0x70.png
84.8 KB View Download
0x78.png
89.2 KB View Download
0x80.png
70.1 KB View Download

Comment 4 by bokan@chromium.org, Dec 14 2016

Awesome, thanks.

Personally, I prefer the lightest of the images so 0x58, but maybe there shouldn't be a difference in alpha for the stroke and just leave it at 0x4D?

Comment 5 by sahel@chromium.org, Dec 14 2016

I tired 0x4D alpha for the stroke when it's hovered. The scrollbar color change by itself is not strong enough to show the differences between thick and hovered. The stroke alpha change makes it visible. 

Comment 6 by bokan@chromium.org, Dec 14 2016

Oh, you're changing the alpha on the whole scrollbar, yes? Have you tried changing the alpha just on the fill? So we'd have separate alphas for stroke and fill:

StrokeAlpha[Hovered]: 4D
StrokeAlpha[Normal]: 4D
FillAlpha[Hovered]: 80
FillAlpha[Normal]: 4D

Comment 7 by sahel@chromium.org, Dec 14 2016

I tired exact same configuration )different alpha values for stroke and fill).
The fill contrast by itself is not enough to show the change between normal(and thick) and hovered.

Comment 8 by bokan@chromium.org, Dec 14 2016

Ah, ok, interesting, in that case I'd go with one of the lightest 3 in your pics above, pick whichever feels best to you.
Project Member

Comment 9 by bugdroid1@chromium.org, Dec 19 2016

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

commit 0f321688bc82199ce1551766e185ac6d9267ede5
Author: sahel <sahel@chromium.org>
Date: Mon Dec 19 21:59:20 2016

Alpha for overlay scrollbars decreased when hovered.

BUG= 669682 

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

[modify] https://crrev.com/0f321688bc82199ce1551766e185ac6d9267ede5/ui/native_theme/native_theme_aura.cc

Comment 10 by sahel@chromium.org, Dec 19 2016

Status: Fixed (was: Assigned)

Comment 11 by dchan@google.com, Mar 4 2017

Labels: VerifyIn-58
Status: Verified (was: Fixed)
9334.23.0 / 58.0.3029.39

Sign in to add a comment