Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 46543 Auto-filled input text box yellow background highlight cannot be turned off!
Starred by 240 users Reported by camspi...@gmail.com, Jun 15, 2010 Back to list
Status: Available
Owner: ----
Cc: tabatkins@chromium.org
Components:
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 350403

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
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 
boxes

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 http://code.google.com/p/chromium/issues/detail?id=1334
The reason I am refiling it is because I suspect that ben.at.chromium.org 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.



 
autofill_bg.png
6.5 KB View Download
Comment 1 by hal.bl...@gmail.com, Jun 15, 2010
Thanks for reposting this.
And contrary to what the original chromium rep said, this is not a WebKit bug.  Safari doesn't experience this.
It would be great if we could get someone else to look at this.
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 yotsumi...@gmail.com, Jun 15, 2010
Please correct it, for dark background which became impossible to read ! ( and very ugly ).

Just remove the !important .
chrome-background-bug.png
1.2 KB View Download
Comment 4 by young.st...@gmail.com, 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 mega...@gmail.com, 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 scott.vi...@gmail.com, 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 jda...@gmail.com, Jun 18, 2010
Please, take care of this...
Comment 8 by intaxity...@gmail.com, 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...
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.
login-yellow.png
2.3 KB View Download
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".
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 bre...@gmail.com, 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. 
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 mnlo...@gmail.com, Aug 29, 2010
Fix this stupid issue
Comment 18 by Deleted ...@, Sep 3, 2010
Remove !important. It's simple. Stupid developers.
I vote for an immediate solution, as this makes data disappear in the input boxes on my dark theme.

Thanks!
Comment 20 by hnat...@gmail.com, 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) {
	$(window).load(function(){
		$(':-webkit-autofill').each(function(){
			$(this).after(this.outerHTML).remove();
		});
	});
}

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.
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 djcor...@gmail.com, 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) {
	$(window).load(function(){
		$('input:-webkit-autofill').each(function(){
			var text = $(this).val();
			var name = $(this).attr('name');
			$(this).after(this.outerHTML).remove();
			$('input[name=' + name + ']').val(text);
		});
	});
}
Comment 23 by 323...@gmail.com, 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 viole...@gmail.com, 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 catal...@gmail.com, Sep 30, 2010
waiting ...
Comment 26 by jda...@gmail.com, Oct 1, 2010
Fixed in latest beta?? I can't repro
Comment 27 by mhorn...@gmail.com, 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 peter@chromium.org, Oct 20, 2010
Labels: -Area-Undefined Area-UI Feature-Autofill
Status: Untriaged
Labels: Mstone-10
Status: Assigned
Comment 30 by yotsumi...@gmail.com, Oct 20, 2010
Thanks :)
Yes!!!
Comment 32 by subj...@gmail.com, Oct 20, 2010
Yayayay
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.
Just remove the !important flag and we'll all be set. What security hurdles does that entail exactly?
Comment 35 by ikebo...@gmail.com, 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.
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
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...
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.

Thanks
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.
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.
Issue 55814 has been merged into this issue.
Labels: -Mstone-10 Mstone-X
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.
> 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 temp01...@gmail.com, Mar 24, 2011
Issue 77322 has been merged into this issue.
Issue 88852 has been merged into this issue.
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.
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.
"""
Labels: -Mstone-14 Mstone-15
Owner: isherman@chromium.org
Blocking: 91375
Labels: -Mstone-15
Blocking: -91375
Issue 101693 has been merged into this issue.
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.

[1] https://bugs.webkit.org/show_bug.cgi?id=66032
Labels: -Restrict-AddIssueComment-Commit
Status: Fixed
Thanks Ilya!

Everyone: I added some brief docs about this to http://trac.webkit.org/wiki/Styling%20Form%20Controls

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!!
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.
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.
Labels: -Mstone-21 Mstone-22
Labels: -Mstone-22 Mstone-23
Comment 64 by bhom...@gmail.com, Jul 20, 2012
Hi Ilya, is M23 the newest target? Here's hoping it won't stay unfixed for another two years.
Thanks, B
Cc: tabatkins@chromium.org
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)

https://gist.github.com/3751098
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?
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.
[1] http://krijnhoetmer.nl/irc-logs/css/20120501
Comment 70 by adys...@gmail.com, 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.
>> 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: [ http://www.w3.org/TR/CSS21/cascade.html#cascading-order ].  There's more discussion of this in the IRC logs that are linked to in comment 69, if you're curious.
Comment 72 by adys...@gmail.com, 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).
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 phistuck@gmail.com, Oct 30, 2012
> I'm not sure whether this approach has since been adopted for placeholder text styling or not
It has. :) See https://bugs.webkit.org/show_bug.cgi?id=64253 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 adys...@gmail.com, 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 simon....@gmail.com, 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 ?...
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 adys...@gmail.com, 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 bhom...@gmail.com, 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 arie.m...@gmail.com, 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){
    window.setInterval(function(){
        $('input:-webkit-autofill').each(function(){
            var clone = $(this).clone(true, true);
            $(this).after(clone).remove();
        });
    }, 20);
}

Comment 87 Deleted
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
autofill.png
39.2 KB View Download
Is there a particular use case we're not aware of for the 3 properties in input:-webkit-autofill {...} requiring !important?

http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css#L760

They are acceptable defaults, but forcing them creates both UX and a design concerns.
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 :)
Project Member Comment 91 by bugdroid1@chromium.org, Mar 10, 2013
Labels: -Area-UI -Feature-Autofill -Feature-Passwords Cr-UI Cr-UI-Browser-Passwords Cr-UI-Browser-Autofill
Blocking: chromium:350403
Comment 93 by vabr@chromium.org, Jun 7, 2016
Components: -UI
Labels: -Pri-2 Hotlist-Polish Pri-3
Cc: -jhawkins@chromium.org
Sign in to add a comment