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

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue 770046
issue 350403

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 46543: Auto-filled input text box yellow background highlight cannot be turned off!

Reported by, Jun 15 2010

Issue description

Chrome Version: 5.0.375.70

What steps will reproduce the problem?
1. Log in to any site that has a member login
2. Log out
3. You will see yellow (#FAFFBD) background on all auto-filled text input 

What is the expected result?
The text input box background color should remain as it is set in user's 
css table

What happens instead?
The text input box background color changes to an undesired value causing 
the page look bad

This is an intentional duplicate of
The reason I am refiling it is because I suspect that who marked the issue as WontFix and closed it, didn't understand what was being asked, and perhaps due to the closed status is not aware of how much activity the issue has and how frustrated some of the community is.

We only ask to have the !important keyword removed, please we need a solution for this that is not a hack.
6.5 KB View Download
Showing comments 2 - 101 of 101 Older

Comment 2 by, Jun 15 2010

Fantastic. I think we all like the idea of notifying users that things are auto-filled where it is appropriate for the design of the site, but in some cases the designer will need to override any style defaults to avoid jarring inconsistency.

Comment 3 by, Jun 15 2010

Please correct it, for dark background which became impossible to read ! ( and very ugly ).

Just remove the !important .
1.2 KB View Download

Comment 4 by, Jun 15 2010

Thank you so much for re-opening this!  As requested, it would be a nice comprimise if the !important were removed from the webkit css.

Comment 5 by, Jun 15 2010

I would suggest the yellow highlight also force the text color to black.  You shouldn't force the background color without also forcing the text color (W3C CSS validator will yell at anyone who uses it about this a LOT).

As for the user styles not overriding the autofill style I see two solutions:
1) Keep !important, since you want to be sure to override any styles the page itself has set.  But apply the user styles AFTER the autofill style.  Then, the user style can also specify !important to override.  Even if the user styles are applied before I suppose the user could simply make a more specific css selector to override the color.
2) Don't use a class for the autofill textbox color (I assume that's how its done if you're using !important) but set the style directly on the element's style property.

Interestingly both solutions could be "sniffed" by JS to determine whether you are using autofill, or less maliciously JS that sets the background color or class on the textbox and then reads it later for some purpose could become confused.  But IMO that's not really good JS anyway (make up your own property names to store arbitrary data on element nodes kthx).

Comment 6 by, Jun 15 2010

I'll echo my sentiments from the previous ticket: Google, please have faith in web developers that they will Do The Right Thing and set their own appropriate colours for autofill.

Comment 7 by, Jun 18 2010

Please, take care of this...

Comment 8 by, Jun 28 2010

Glad to see this being re-opened. Sucks having to disable autocomplete on all my forms/fields to fix a layout bug in one browser... Adding an autocomplete="off" attribute to your forms and fields disables Auto Fill and this behavior without the need of any extra css/etc but that's not a solution either - taking away something useful to prevent a certain undesired visual behavior is no good...

Comment 9 by, Jul 1 2010

Yeah, i agree, this makes my site so ugly, just take a look at attach. Disable autocomplete on my forms, as intaxity.obry said, is removing something useful. Remove !important would be great.
2.3 KB View Download

Comment 10 by, Jul 17 2010

I'm glad this was reopened. This issue dates back to 2008 and I'm very disappointed it was so quickly dismissed and ignored from then on.

Please fix this and remove "!important".

Comment 11 by, Jul 17 2010

agree with topic's point.

if chrome want to notify user the field is changed, chrome developer should think of the other way rather than modify website's code, the !important make website ugly.

Comment 12 by Deleted ...@, Jul 26 2010

Two years!!!!!!! This is just retarded.

Comment 13 by Deleted ...@, Aug 1 2010

This is pure retardness <_<

Comment 14 by, Aug 8 2010

Let's get on with it and remove the dang thing. I want my sites to look good

Comment 15 by Deleted ...@, Aug 24 2010

Remove the !important keyword. damn.

Comment 16 by, Aug 25 2010

It's really not that hard, Google. It's quite a pain.

Chromium shouldn't be apart of web-kit, web-kit should be apart of Chromium.

Help us designers out and just give us some leeway with this. Remove the damn !important keyword already... >.>

Comment 17 by, Aug 29 2010

Fix this stupid issue

Comment 18 by Deleted ...@, Sep 3 2010

Remove !important. It's simple. Stupid developers.

Comment 19 by, Sep 5 2010

I vote for an immediate solution, as this makes data disappear in the input boxes on my dark theme.


Comment 20 by, Sep 12 2010

Here's my workaround based on JQuery. Works similar to one of solutions proposed in discussion of  issue 1334 , but is more common.

if (navigator.userAgent.toLowerCase().indexOf("chrome") >= 0) {

Actually it kills all autocomlete in Chrome for your page, but that's not that high price for having correct CSS background for inputs. Though you can read value of the input before it is being destroyed and then set the value of newly created element to it, but for some reason it didn't worked with '[outerHTML="html of created element"' selector.

Comment 21 by, Sep 16 2010

Only just run into this problem myself. Our input fields have overriding images as the background. This gives our site an aesthetically pleasing, clean and tidy feel to it. That is our decision to make, as the site designers. Why on earth should a browser dictate the design of a universally accessible website?  

Jesus, I expect this from IE6, but Chrome?! It's 2010! After the eventual, slow death of IE6 I thought the idea of adding per-browser styling would be dead? Don't go down this road, google. This is embarrassing.

Comment 22 by, Sep 22 2010

I've modified hnatt88's code as he wrote, so that autocomplete actually does work;)

if (navigator.userAgent.toLowerCase().indexOf("chrome") >= 0) {
			var text = $(this).val();
			var name = $(this).attr('name');
			$('input[name=' + name + ']').val(text);

Comment 23 by, Sep 22 2010

hehehe ... a typical programmer vs designer mistake ... making something the same color on EVERYTHING is .. mmm well ... something a programmer would do, because it makes sense logically. Yeah let's make it yellow...  :-) hihi

If Google wants to make textboxes yellow, why should we bother as developers to disable that ? Chrome users will notice the mistake for themselves and will not hold the site's designer accountable ... they'll think 'This Chrome browser looks bad' :-)

Take it easy

Comment 24 by, Sep 28 2010

The stubbornness of Google developers on this issues is really stupid. 
Just remove the damn !important. Is it that hard?

Comment 25 by, Sep 30 2010

waiting ...

Comment 26 by, Oct 1 2010

Fixed in latest beta?? I can't repro

Comment 27 by, Oct 12 2010

Not only is the a giant kick in the face to developers, it's affecting user experience on some websites.

If you're not bothered about having devs and users on your side, who else is there?

Comment 28 by, Oct 20 2010

Labels: -Area-Undefined Area-UI Feature-Autofill
Status: Untriaged

Comment 29 by, Oct 20 2010

Labels: Mstone-10
Status: Assigned

Comment 30 by, Oct 20 2010

Thanks :)

Comment 31 by, Oct 20 2010


Comment 32 by, Oct 20 2010


Comment 33 by, Oct 20 2010

Don't get too excited.  There are some real security and usability hurdles with this that may or may not be tractable.  Security trumps aesthetics, but maybe we can find a solution that allows for both.

Comment 34 by, Oct 21 2010

Just remove the !important flag and we'll all be set. What security hurdles does that entail exactly?

Comment 35 by, Oct 21 2010

At a guess, it's because the user needs to have some notification that their (potentially) personal information has just been handed over, whether they were expecting it or not.

Comment 36 by, Oct 21 2010

But this has never been a problem in the past with other browsers, so why should the user expect chrome to behave any differently.

The user gets to choose the first time the enter a password/etc whether they want it saving and autofilling or not, from then on they should just remember that chrome will be doing the work for them, they shouldn't need any visual representation ...especially as the overriding background color and image make some pages look badly designed

Comment 37 by, Oct 21 2010

Add a drop-down bar or something to notify the user that there's AutoFill information available (and also maybe include a selection box to chose from different AutoFill profiles the user might have setup)... That should get the user's attention, let them know what's going on, allow them to respond or ignore the notification bar and continue with their business without the website/form they're visiting looking like a christmas tree...

Comment 38 by, Oct 21 2010

you want to know what is really not secure? when you can't see you're username/password because someone decided it was a good idea to override the background color without overriding the foreground color. security aside, i'm with the rest, it's not up to chromium devs to tell the internet as a whole how their sites should be displayed. i never read any spec that says auto-fill inputs will have a yellow background color. 

standards > security > aesthetics... hasn't IE6 taught you anything?

Comment 39 by Deleted ...@, Oct 21 2010

Can Chrome users not work out for them selves that if a form is filled in, and they didn't just do it, then Chrome must have done it for them?

There are only a few rare cases when it would be a security issue to auto-fill a username and password even after the user had told Chrome to store it.
In these situations, users that do not realise something's wrong are not going to take any notice of the yellow background.

In my opinion it provides absolutely zero 'security' and negative usefulness.

Please just get rid of it.


Comment 40 by, Oct 22 2010

I agree 100%. The user has obvious already visited the site before and given Chrome the go-ahead to AutoFill in the first place. The user has already given prior consent to Chrome, visited the website, and obviously trusts both Chrome and the website with this information. Unless you're suggesting Chrome has a problem with storing or autofilling without the user's permission, then I don't see any security issue here with removing a useless, tacky, and annoying "!important" keyword from the built-in CSS; thats absurd. The information pertains to that website, meaning the owners of the site already have the information. Why would a website want to steal login info from it's own users? The point is, the user has already inputted the information into the website once before. The only thing the keyword is doing is breaking up the look-and-feel and flow of the websites which has taken hours upon hours of development and money. Don't get me wrong, Chrome is an awesome browser, which I have had no problem making my default browser. I would just like my website represented how I designed it to look. Besides, for the sake of those users out there oblivious to the fact they gave prior consent, it wouldn't hurt for the designer behind the website to create his or her own method of notifying the user in a way that best suites the website's design. Rather then a hideous off-whitish yellow color that doesn't even change the foreground color.

Please just make the change. There is no valid excuse not to. It's already taken long enough for this simple issue to be recognized. I respect the Chrome developers for creating an awesome browser, but please just take care of this quickly and painlessly. If you need to add a notif bar that drops down then so-be-it. But please just get rid of that keyword. The site already has the information from prior visits, and so does Chrome. If any damage were to be done, it would've already be done on the first visit.

Comment 41 by, Oct 25 2010

Labels: Restrict-AddIssueComment-Commit
Thank you for your comments folks; we're carefully considering how best to approach this issue.  For now, turning off comments.

Comment 42 by, Oct 29 2010

 Issue 55814  has been merged into this issue.

Comment 43 by, Dec 7 2010

Labels: -Mstone-10 Mstone-X

Comment 44 by, Jan 12 2011

We chatted some about this, and need to talk more.

There are two parts here.

First, setting a background color without also setting a foreground color is a recipe for badness.  We need to set the text color to black in the same way we set the background color to yellow, so that things will be readable.  The original, primary issues behind this bug relate to this issue and it obviously needs a fix.

Second, there is the question of whether and how users or authors can override us.  It's important to note that it's not a security issue for us to allow overrides, as an evil site already can hide an autofilled field in multiple ways so the user doesn't see it.  So we don't need to worry about that side of things.

However, if we allow arbitrary overrides, the comments above demonstrate pretty clearly that we'll get overridden because authors think something else looks nice.  "Consistent experience across the web for users" is very important here.  So the question we still need to answer is "is a consistent experience more important than an author's aesthetic choice for some form fields".  My personal opinion is "no", but the autofill team should decide this for themselves, hence the need for further discussion.

Comment 45 by, Jan 12 2011

> First, setting a background color without also setting a foreground color is a recipe for badness.  We need to set the text color to black in the same way we set the background color to yellow, so that things will be readable.  The original, primary issues behind this bug relate to this issue and it obviously needs a fix.

This is being tracked in  bug 52993 , which I need to cycle back to.

Comment 46 by, Mar 24 2011

 Issue 77322  has been merged into this issue.

Comment 47 by, Jul 11 2011

 Issue 88852  has been merged into this issue.

Comment 48 by, Jul 11 2011

Labels: -Mstone-X Mstone-14 Feature-Passwords
Two follow-up points here:

(1) The reporter in  issue 88852  notes that "designers usually use yellow backgrounds on notifications and warning messages. When a warning message is displayed about the auto-filled fields, the two colors will clash".

(2) It's probably worth taking another look at what other browsers do to indicate autofill.  Based on what has been said here and in other bugs, it sounds like other browsers allow site designers to override the colors.

Targeting to M14 for triaging purposes.  This bug has been sitting open for a while now.  We should settle on a course of action and go with it.

Comment 49 by, Jul 11 2011

Some additional, concrete use cases from an email correspondence:

The site we're currently working on utilises a custom background graphic for the text entry fields. When Chromium over-rides this, it poses three problems for us.

1. A break in consistency for our site, covering the entire graphic in block yellow colour (all entry fields otherwise look the same)

2. A conceptual clash with minor user error notifications (which are yellow)

3. Depending on theme (the site changes appearance / colour with the seasons) it breaks design entirely. For instance, on the winter (blue) theme, we use yellow as a complementary colour to denote importance in buttons. This field now may seem like a button to our target elderly demographic.

Comment 50 by, Jul 22 2011

Labels: -Mstone-14 Mstone-15

Comment 51 by, Aug 3 2011


Comment 52 by, Aug 12 2011

Blocking: 91375

Comment 53 by, Aug 29 2011

Labels: -Mstone-15

Comment 54 by, Aug 29 2011

Blocking: -91375

Comment 55 by, Oct 26 2011

 Issue 101693  has been merged into this issue.

Comment 56 by, Apr 6 2012

Labels: Mstone-20
Status: Started
This should be landing in WebKit soon [1], and picked up in Chromium shortly thereafter, targeted at the M20 milestone.  Thanks for everyone's patience on this bug.


Comment 57 by, Apr 25 2012

Labels: -Restrict-AddIssueComment-Commit
Status: Fixed

Comment 58 by, Apr 26 2012

Thanks Ilya!

Everyone: I added some brief docs about this to

Basically you can style `background-color` and foreground `color` with the `:webkit-autofill` pseudo-selector:

    input:-webkit-autofill { background: papayaWhip; color: hotPink; }

Comment 59 by Deleted ...@, May 1 2012

I don't understand why Google would force style onto a website in the first place. Its against web standards. If the creator of the website doesn't want it to be highlighted, then it shudn't be forced. Also, this would be the easiest option to give us. Firefox gives us about:config to let us customise to our hearts content, why not Chrome? Makes me wonder why i switched from Firefox but then i remember how slow that's been getting.

All i want is an option to turn this off for myself, leave it on by default, i really cudn't care less. Just give me the damn option its awful!!

Comment 60 by, May 1 2012

It's due to be fixed soon so that web authors can disable it if need be. Complaining at this stage really is counter-productive.

Comment 61 by, May 2 2012

Labels: -Mstone-20 Mstone-21
Status: Started
Unfortunately, the fix introduced regressions, and consequently had to be reverted.  There's another approach that seems promising, which I hope to implement for M21.

Comment 62 by, Jun 12 2012

Labels: -Mstone-21 Mstone-22

Comment 63 by, Jul 16 2012

Labels: -Mstone-22 Mstone-23

Comment 64 by, Jul 20 2012

Hi Ilya, is M23 the newest target? Here's hoping it won't stay unfixed for another two years.
Thanks, B

Comment 65 by, Jul 28 2012

In response to @bhomoki: Unfortunately, I don't have a lot of time to devote to Autofill currently, and the alternate approach that I mentioned in comment 61 is somewhat involved.  Hence, I'm not exactly sure when I'll be able to get to this, though it's still on my short list of Autofill bugs I'd really like to get fixed.  If you or anyone else is eager to fix this sooner, and wants to get their hands dirty with some WebKit code, I'd be happy to help you get set up.

Comment 66 by Deleted ...@, Sep 19 2012

Here is that javascript hack in coffeescript, with a parent element to help target the right input field (if multiple fields have the same name)

Comment 67 by Deleted ...@, Oct 12 2012

please google send us the possibility to set our personal colors and backgrounds, me i needed to remove autofill from inputs and textareas :/

Comment 68 by Deleted ...@, Oct 25 2012

It's very sad this is going for more than 2 years and the solution is still not here. We are having 3D rendering in web browsers but we can't change an input background color yet. 

Really guys, what is the deal?

Comment 69 by, Oct 29 2012

Labels: -Mstone-23
Owner: ----
Status: Available
Unfortunately, it turns out to be hard to set the yellow color by default, but enable site authors to override it if they would like to.  The obvious change, to simply remove the "!important" from the WebKit base style, causes even "input { background: white; }" to override WebKit's "input::autofilled { background: yellow; }".

Tab Atkins suggested a more involved approach, which at the time was also being considered for styling placeholder text for <input> elements.  Roughly, we could create an ::autofill pseudo element, which can be styled by the UA, and can be overridden by site authors who want to explicitly override it, but not by accident just by changing the styling for a plain ol' <input> element.  This is fleshed out a bit more in the IRC logs at [1].  I'm not sure whether this approach has since been adopted for placeholder text styling or not, but it might be a helpful starting point for anyone interested in working on this bug.

Comment 70 by, Oct 29 2012

> The obvious change, to simply remove the "!important" from the WebKit base style, causes even "input { background: white; }" to override WebKit's "input::autofilled { background: yellow; }".

That sounds like a bug. input::autofilled should have priority.

Comment 71 by, Oct 29 2012

>> The obvious change, to simply remove the "!important" from the WebKit base style, causes even "input { background: white; }" to override WebKit's "input::autofilled { background: yellow; }".
> That sounds like a bug. input::autofilled should have priority.

Alas, this is how it is specified in the spec: [ ].  There's more discussion of this in the IRC logs that are linked to in comment 69, if you're curious.

Comment 72 by, Oct 29 2012

Ouch, indeed, after reading the IRC log this is a bit more painful than expected...

> # [01:06] <isherman> fantasai: is there any way to achieve that in the CSS model?

Quite the change, but you could always add a !keyword for it, eg background: yellow !-webkit-overrides(input); }. That does have a lot of implications, but it could end up useful elsewhere in the UA stylesheet (and even more so in user-defined UA stylesheets).

Comment 73 by, Oct 29 2012

I don't currently have time to work on a more involved change along these lines, but I'd be happy to point you in the right directions if you'd like to try pursuing this yourself.  Discussing your idea with some folks on the #css w3c channel would probably be a good starting point :)

Comment 74 by, Oct 30 2012

> I'm not sure whether this approach has since been adopted for placeholder text styling or not
It has. :) See which is marked as fixed.
@adys.wh -
If you are interested in implementing this, look into the patch that is attached to the bug and it might make it a whole lot easier for you.

Comment 75 by, Oct 30 2012

I'll have a look at it, but most likely won't have enough time to work on a patch (especially as I don't have anything set up), I'm afraid.

Comment 76 by, Oct 30 2012

This is a little hack i use for the moment, it work on Chrome 22.0.1229.94 m :
input:-webkit-autofill {
    -webkit-box-shadow:0 0 0 50px white inset; /* Change the color to your own background color */

If you have styled the input on focus with box-shadow, you need to re-styled it :
input:-webkit-autofill:focus {
    -webkit-box-shadow: /*your box-shadow*/,0 0 0 50px white inset;

But it doesn't solve the real problem : why can't we style the autofilled input ?...

Comment 77 by, Nov 7 2012

PLEASE fix this bug. it is really quite annoying. i cant seem to find a hack that will work on my current system.

Comment 78 by Deleted ...@, Nov 7 2012

Thx Simon for your hack :)
Unfortunately text color is always black ...
So chromium developpers group,PLEASE fix your OLD BUG !!

Comment 79 Deleted

Comment 80 by, Nov 7 2012

@bhomoki this really doesn't do anything to help the bug. It's very minor and not easy to fix, that makes it low priority. You saw how many other issues there are open right?

Comment 81 by, Nov 7 2012

My bad, sorry. I take it back.
I'd really like to see this one fixed sooner or later as it is really a high-profile bug, showing up on any signin forms anywhere in the wild. A simple icon, defined as a background image would be killed by this yellow bg. Also, setting a background-color without setting a foreground color is not something I would call best practice.

A lot of web devs are waiting for this fix and I understand it's not easy to fix. And I understand it's in the cue for 3 years already. And counting. And it doesn't have an owner or a target milestone anymore. That's too bad.

Comment 82 by Deleted ...@, Nov 15 2012

hey @hnatt88's and @djcor...  thanks for solution! : )

Comment 83 by Deleted ...@, Dec 12 2012

@simon Thanks 
@quentin my code solve the text color problem

This solved my problem:
input:-webkit-autofill {
    -webkit-box-shadow:0 0 0 50px black inset; /* Change the color to your own background color */
    -webkit-text-fill-color: white;

input:-webkit-autofill:focus {
    -webkit-box-shadow: /*your box-shadow*/,0 0 0 50px white inset;
    -webkit-text-fill-color: white;

Comment 84 by, Dec 13 2012

The javascript by #22 doesn't seem to be working every time if you F5 a few times.

Now I just use the box-shadow solutoin as by #83, however I would also still like this to be resolved because I was using box-shadow normally for my inputs as well for a nice glow.

Comment 85 by Deleted ...@, Dec 14 2012

bump for correction

Comment 86 by Deleted ...@, Jan 18 2013

This which works for me:

if(navigator.userAgent.toLowerCase().indexOf("chrome") >= 0 || navigator.userAgent.toLowerCase().indexOf("safari") >= 0){
            var clone = $(this).clone(true, true);
    }, 20);

Comment 87 Deleted

Comment 88 by, Jan 19 2013

When "google" w'll solve this inconvenient?

I've been making the structure to my form and I came across with this problem autofill
goes above my design.

Why I can't edit autofill design??

In my form, I put 1 image in background for each input, I solve the background color with:

input:-webkit-autofill {
	-webkit-box-shadow: 0 0 0px 1000px white inset;

But I can't put the images working....
I appreciate that not let the webdevelopers on hand
39.2 KB View Download

Comment 89 by, Jan 21 2013

Is there a particular use case we're not aware of for the 3 properties in input:-webkit-autofill {...} requiring !important?

They are acceptable defaults, but forcing them creates both UX and a design concerns.

Comment 90 by, Jan 22 2013

Labels: Restrict-AddIssueComment-EditIssue
As discussed above, we'd like to fix this bug, but the technical implementation is somewhat involved, so this bug is in need of an owner with time to work on it.  I'm going to re-close this bug to random comments, as they're mostly just rehashing previous one.  Fee free to email me directly if you'd like to own this bug or have additional comments that you don't think are already covered by the previous 90 comments.  (If you're a Chromium project member and want to work on this bug, no need to email -- just go for it :)

Comment 91 by, Mar 10 2013

Project Member
Labels: -Area-UI -Feature-Autofill -Feature-Passwords Cr-UI Cr-UI-Browser-Passwords Cr-UI-Browser-Autofill

Comment 92 by, Mar 8 2014

Blocking: chromium:350403

Comment 93 by, Jun 7 2016

Components: -UI
Labels: -Pri-2 Hotlist-Polish Pri-3

Comment 94 by, Jul 13 2016


Comment 95 by, Dec 15 2016

 Issue 350403  has been merged into this issue.

Comment 96 by, Mar 7 2017

 Issue 698761  has been merged into this issue.

Comment 97 by, Mar 7 2017

Friendly ping!!
@isherman/tabatkins,Could you please look onto this issue & update the thread.
Thank you!

Comment 98 by, Mar 7 2017

Re: #97: There hasn't been any status change here.  This bug remains available, in need of an owner, and I remain open to helping anyone who wants to work on it.

Comment 99 by, Sep 29 2017

Blocking: 770046

Comment 100 by, May 1 2018

Status: Untriaged (was: Available)

Comment 101 by, May 7 2018

Status: Available (was: Untriaged)
We want to highlight the fields filled with Chrome. The question is how to do it otherwise.
Showing comments 2 - 101 of 101 Older

Sign in to add a comment