New issue
Advanced search Search tips

Issue 911247 link

Starred by 2 users
Status: Duplicate
Merged: issue 898278
Owner:
lgrey@chromium.org
Closed: Dec 4
Cc:
phanindra.mandapaka@chromium.org
style-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

CSS graytext gets rendered as (0,0,0)

Reported by gregoryd...@gmail.com, Dec 3 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

Steps to reproduce the problem:
1. Open the attached page

What is the expected behavior?
The first item is disabled, and thus inherits the user agent style of "color: graytext". The item should appear gray on the screen.

What went wrong?
The item appears black.
Note, it is following the rules defined at https://www.w3.org/wiki/CSS/Properties/color/keywords for graytext, but it seems like the browser and OS should be able to display a solid gray color

Did this work before? Yes This might be linked to the OS X version. I just upgraded to 10.14.1 from 10.13.x and that's when I noticed it

Does this work in other browsers? No
 Chrome and Firefox both show the problem
Safari does not show the problem

Chrome version: 70.0.3538.110  Channel: stable
OS Version: OS X 10.14.1
Flash Version: 

I have tried this with both the "light" and "dark" themes in 10.14.1 to see if that makes any difference, but it does not. Safari does show the text as gray, not black.
graytext.html
284 bytes View Download

Comment 1 by gregoryd...@gmail.com, Dec 3 

It is only impacting OS X. Windows Chrome works fine. It is also only impacting select elements that are expanded with the size attribute. Collapsed select elements display the color correctly. See the attached graytext_2cases.html
graytext_2cases.html
459 bytes View Download

Comment 3 by swarnasree.mukkala@chromium.org, Dec 4

Labels: Needs-Bisect Needs-Triage-M70

Comment 4 by phanindra.mandapaka@chromium.org, Dec 4

Cc: phanindra.mandapaka@chromium.org
Labels: -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable Triaged-ET Target-71 M-71 FoundIn-71 FoundIn-70 FoundIn-72
Owner: lgrey@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on the reported chrome 70.0.3538.110 and the issue seems to be fixed in latest canary 73.0.3629.0 using Mac 10.14.0. Below is the reverse bisect information for same.

Bisect Info:
================
Good build: 72.0.3697.0
Bad build:  72.0.3696.0

CHANGELOG URL:
You are probably looking for a change made after 604110 (known good), but no later than 604111 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/ef3fa57316656238bf3620b61b140272fa5375ae..36de6d6adeb99fb05f79daab1868568f4cca367c

Suspect: https://chromium.googlesource.com/chromium/src/+/36de6d6adeb99fb05f79daab1868568f4cca367c
Reviewed-on: https://chromium-review.googlesource.com/c/1305498

Leonard Grey:Please confirm the issue and help in re-assigning if it is not related to your change. Adding RBS label for M-71 feel free to change it if not required.

Thanks!

Comment 5 by lgrey@chromium.org, Dec 4

Mergedinto: 898278
Status: Duplicate (was: Assigned)
Yup, that was it
►

Sign in to add a comment