input field caret colour ignores -webkit-text-fill-color:
Reported by
justin.m...@tibit.com,
Mar 8 2016
|
|||||
Issue descriptionChrome Version : Version 47.0.2526.106 Built on Ubuntu 14.04, running on LinuxMint 17.2 (64-bit) URLs (if applicable) : http://jsfiddle.net/Justin_Maxwell/v7751q2w/11/ Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: Firefox: OK 43.0.4 IE: What steps will reproduce the problem? (1) Go to linked JS fiddle, enter text in input text field (2) Observe text and caret are different colours * (3) Add a value and click submit to record for autofill (4) Refresh (5) Select autofill value from step 3 (6) Click into autofilled text field value (6) Observe caret is black and near-invisible, while text is legible What is the expected result? The caret should always be the same colour as the text fill (or stroke?). What happens instead? The caret for autofill is always black, and hence invisible. Please provide any additional information below. Attach a screenshot if possible. Even though the use case and CSS is hacky, it is a widely used approach to style Chrome autofill. While there are many many requests for better CSS for autofill in Chrome, addressing those is a major piece of work. So in the meantime, we have: input:-webkit-autofill { color: #F88 !important; -webkit-text-fill-color: #8F8 !important; -webkit-box-shadow: 0 0 0px 1000px #00B inset; } Or similar. Setting the caret to use the -webkit-text-fill-color computed/derived value or rule, (instead of the simple color value) would allow the use of darker theme colours with Chrome autofill, and sounds 'simpler(?)'. There are tests in the repo that describe themselves as checking that the caret always has the same colour as the text. * a different colour for the cursor is a funky design 'feature' best kept secret from designers and 'designers' for their own good. Regardless, being able to see the cursor (assuming the text is visible) is more !important. nb: a quick search led me to src/ui/gfx/render_text.h line 724 not sure if helpful... // The color used for the cursor. SkColor cursor_color_;
,
Mar 10 2016
A similar issue has been discussed in bug 390459.
,
Mar 10 2016
I'm inclined to say that the browser style for -webkit-autofill [1] should be updated to set hard defaults for -webkit-text-fill-color and -webkit-box-shadow and any other sneaky attributes that might change the text color. Of course, even better would be to finally fix bug 46543. Patches very welcome! (Though, if you want to work on that bug, please read through the comment history, especially comment #69 [2], which discusses technical details of the most promising implementation strategy.) [1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/html.css&l=560-564 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=46543#c69
,
Mar 31 2017
I'm not sure why this got assigned to me. I'm not going to be able to look at it.
,
Apr 16 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 15 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by rnimmagadda@chromium.org
, Mar 10 2016Components: UI>Browser>Autofill
Labels: -Type-Bug -Pri-3 M-50 OS-Linux OS-Mac OS-Windows Pri-2 Type-Bug-Regression
Owner: tsepez@chromium.org
Status: Assigned (was: Unconfirmed)