New issue
Advanced search Search tips

Issue 902276 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Unable to see Favicon icon when mouse-hovered on chrome://settings tab-strip.

Reported by aiman.an...@etouch.net, Nov 6

Issue description

Chrome Version: 72.0.3603.0 (Official Build) 5edf276f371d84cdd49179c8cb6a3dd210bdfe20-refs/branch-heads/3603@{#1} (32/64 Bit)

OS: Windows 10 only.

Precondition:
1. On Windows machine, Right click on desktop and select Personalize
2. Select Colors option.
3. Select check box for 'Title Bar' under Accent colors
4. Select 'Default Blue' color.      

Steps to reproduce:
1. Launch chrome, open chrome://settings page.
2. Open another NTP and mouse-hover on adjacent chrome://settings tab-strip.
3. Observe.

Actual Result: Unable to see Favicon icon when mouse-hovered on chrome://settings tab-strip.  
Expected Result: Should be able to see Favicon icon when mouse-hovered.

This is Regression Issue broken in M-70, and below is the per-revision bisect info.
Good Build: 70.0.3515.0 (Revision:581085)
Bad Build: 70.0.3516.0 (Revision:581409)

You are probably looking for a change made after 581329 (known good), but no later than 581330 (first known bad).

CHANGE-LOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/53d72b57049b725795126fd4b7f4337332fe1004..5420a4f2471b3223735947dab88d3c0474de89be

Suspecting: https://chromium.googlesource.com/chromium/src/+/5420a4f2471b3223735947dab88d3c0474de89be

orinj @: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note:
1. Issue is Win 10 specific and is not seen on Win(7,8,8.1), Mac(10.13.1,10.13.6,10.14.2) and Linux(14.04 LTS) OS.
2. Issue is also seen on Stable #70.0.3538.77, Beta #70.0.3538.54, Dev #72.0.3602.2 build.

Kindly refer the attached screen-cast.

Thank You!



 
Actual Result.mp4
1.2 MB View Download
Expected Result.mp4
1.4 MB View Download
Cc: orinj@chromium.org
Owner: rameier@chromium.org
Assigning to rameier@ because the color system he's been working on might be able to handle this kind of situation.

I was helping out with color changes before, and the suspected CL fixed problems more serious than favicon visibility (tab accessibility, text readability in popular themes) so resolving the present bug is not a matter of undoing or refining previous fixes.  Color changes cascade and bounce around with the system in place today, so work on a more comprehensive long-term solution is in progress.

Personally I think Chrome should be unaffected by external OS color changes until an integration step checked by a Chrome-smart color control system -- bad/inaccessible color combinations would simply not be committed for display.  But I think pkasting@ and rameier@ have some ideas about how to work well with existing themes and OS color changes.  Their input/output/mixing approach is both more clever and more likely to launch than my blunt data-driven approach, so that is probably what will end up resolving this bug.

rameier@, let me know if I can be of some help.
Labels: Hotlist-DesktopUIConsider
Labels: Group-Tab
Labels: -Hotlist-DesktopUIConsider Hotlist-DesktopUITriaged
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
Just to update: 
Still we are able to reproduce the issue on latest canary #72.0.3609.3 on Windows(7,8,8.1,10) OS. 

@rameier: Could you please take a look into this issue.

Kindly find the attached screen-cast for reference.

Thank you.
Canary_Behaviour.mp4
1.1 MB View Download
Owner: bettes@chromium.org
Unfortunately I don't know that this is something we can easily fix programmatically in the general case - as favicons across the web are so varied, and I don't think we want to be modifying their appearance on our end.

We may, however, be able to solve the Chrome-specific cases by modifying the icons themselves in a way that will ensure they're visible on any background (for example - adding a light-colored outline around the icon, which might even blend into the background of the default browser, but ensure the icons are called out in a non-default case).

This is very much a design question though and not something I feel qualified to answer - tossing over to bettes@ for input.
Labels: -M-70 -Target-72 -Target-71 -Target-70 M-73 Target-73
For monochromatic built-in icons, see also bug 856345.

Sign in to add a comment