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

Issue 593158 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

input field caret colour ignores -webkit-text-fill-color:

Reported by justin.m...@tibit.com, Mar 8 2016

Issue description

Chrome 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_;

 
Cc: ziran....@samsung.com isherman@chromium.org
Components: 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)
====================================

Good Build:

35.0.1892.0    Base Position: 257070


Bad Build:

35.0.1896.0    Base Position: 257383

=====================================

Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 49.0.2623.87

This is a regression issue broken in M35, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/7e856dde942357f969d757de61db277395c2c1f9..ff4657ee6daaa1470e70e1cd12f4f936ac02a631

Suspecting Commit: ac9b92fa3e33e61609d36c4b1a04e44a4ada978e

Review URL: https://codereview.chromium.org/148413002

@ziran.sun/tsepez: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.
A similar issue has been discussed in bug 390459. 
Labels: -OS-Linux -OS-Windows -M-50 -Pri-2 -Type-Bug-Regression -OS-Mac OS-All Pri-3 Type-Bug
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

Comment 4 by tsepez@chromium.org, Mar 31 2017

Owner: ----
Status: Available (was: Assigned)
I'm not sure why this got assigned to me. I'm not going to be able to look at it.
Project Member

Comment 5 by sheriffbot@chromium.org, Apr 16 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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

Comment 6 by ma...@chromium.org, May 15 2018

Owner: se...@chromium.org
Status: Assigned (was: Untriaged)

Sign in to add a comment