“autocomplete=off is ignored on non-login input elements”

https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164

by wmil • 10 years ago

212 250 10 years ago

bugs.chromium.org

jaitsu• 10 years ago

I ranted about this on my blog whilst drunk, and then went off in a tangent, you can find it at jameshalsall.co.uk, 2nd post.

This really makes me uncomfortable, standards are there for a reason, you don't just ignore them because you don't agree with them.

Karunamon• 10 years ago

And sometimes the standard is wrong. The page telling the browser that the user isn't allowed to auto fill a form puts too much control in the hand of the page.

DanBC• 10 years ago

Sure. Fix the standard, don't just make shit up.

Maybe the standards process is broken, in which case that's something that needs fixing. I can't see why the four browser makers can't create their own browser standards.

saulr• 10 years ago

The standard is only a hint to the user agent, not a MUST.

kuschku5• 10 years ago

Except, it is a SHOULD.

zimpenfish2• 10 years ago

standards are there for a reason you don't just ignore them because you don't agree with them

People always ignore the bits of the standards they don't agree with; taking an entirely dickish and non-random example e.g.

<img src="http://secure.gravatar.com/avatar/df0e70f6e810442b86d701afcb...

https://html.spec.whatwg.org/multipage/ says "4.8.4.1.1 Except where otherwise specified, the alt attribute must be specified and its value must not be empty"

Or having 4 <section> but only 3 </section>.

raldi3• 10 years ago

Good. It's my browser. I get to turn its features on and off, not you.

And that goes double on my phone.

As a compromise, I'd accept a prompt like:

    +---------------------------------------+
    |    This page recommends we disable    |
    |    autocomplete. What do you think?   |
    |[Okay] [Fuck them; autocomplete anyway]|
    +---------------------------------------+

taf2• 10 years ago

99% of the time I agree but imagine for a second a user management system that lets an administrator edit other users profiles and a browser that decides to autocomplete the email fields in the form or name etc... Better hope auto save is not a thing...

Of course when it comes to buying things online give me my autocomplete or I hate you

- love your recommendation for a browser prompt!

iamdave4• 10 years ago

imagine for a second a user management system that lets an administrator edit other users profiles

Just my $0.02, and this might be taking us out of the scope of discussion (maybe not?) but I can't think of a good business reason why an administrator needs to control whether or not the end user can use a function like autocomplete. That seems like micromanaged minutiae that will annoy my users more than help them if it's something they rely on for data entry. And if that's the case...why bother touching it in the first place?

Training/security policy that says "Be mindful of how you use this feature" to avoid any awkward NDA/HR situations? Sure, absolutely 100%.

Curious what others think on this?

yborg• 10 years ago

It's Google's browser. This is your mistake for using Google's browser if you don't agree with what Google wants their browser to do.

Myrth• 10 years ago

Exactly. I have no idea why people blamed IE for not following standards. It was totally all of its users' fault for using it.

LionessLover2• 10 years ago

Uhm.... your reply makes no sense - what he says is in support of the Chrome decision.

jobead• 10 years ago

If you want to "turn it's features on and off", then why does the Chromium team's stance of "extensions are the standard way to enable custom behavior"[0] not apply here???

This is a classic unfortunate case of using data from the masses to drive a bad design choice because it increases "usage" along an arbitrary axis.

[0] https://news.ycombinator.com/item?id=11729287

comex• 10 years ago

In the phrase you quoted, "custom" means "different from the default". It's about a choice between building customization into the browser (in the form of preferences) and relying on extensions to provide it. And it does apply here: there is no preference to honor autocomplete=off. If you want your Chrome instance to do so... find an extension.

(Though, since my quick search of the Chrome Web Store found a lot of [presumably no longer necessary] extensions to disable autocomplete=off but none to do the opposite, you might have to write it yourself. It should suffice to change "off" to an unrecognized string, as mentioned in the last comment on the issue report.)

forgottenpass• 10 years ago

The Chromium team's stance of "extensions [...]" is better understood as: "get the fuck off my lawn."

_lce0• 10 years ago

I agree.

And nothing prevents us from dropping, on ~/.js

    setTimeout(() => {
      Array.from(
        document.querySelectorAll('[autocomplete]')
      ).forEach(
        el => el.removeAttribute('autocomplete')
      );
    }, 250);

jessedhillon• 10 years ago

Is ~/.js something I should know about? Somewhere to add snippets of Javascript which are run unconditionally by Chrome on any page load?

nness• 10 years ago

The Dotjs extension is no longer maintained, just for those looking at this and wondering if it's worthwhile.

dasil003• 10 years ago

Take it up with the standards body then.

Presumably this came about because some framework or something started including bad default attributes, and then Chrome responds by ignoring the meaning of the specification in order to "improve UX". But in the end what happens is that the specification becomes meaningless and we're back to the browser wars where you have no way of knowing how anything works except a continuous testing process to vet the veracity of the spec for any browser you are targeting, and of course this is subject to change on a whim by Google.

Will it improve the UX? Maybe... if Google is correct in its unilateral assumptions. But one thing for sure is that as a developer this costs you time, and it hurts the most if you are a well-intentioned developer who is trying to make the correct choice for your specific use case.

dragonwriter10• 10 years ago

Take it up with the standards body then.

But, in the standard, the autocomplete attribute is a hint to the user agent, not an authoritative direction. [0]

The people who want to make it an authoritative direction ought, as you say, to take it up with the standards body.

[0] https://html.spec.whatwg.org/multipage/forms.html#autofill : "User agents sometimes have features for helping users fill forms in, for example prefilling the user's address based on earlier user input. The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature." (emphasis added)

ori_b2• 10 years ago

Take it up with the standards body then.

I'd like to, but I doubt they'll listen. As a compromise, I'd be happy to have browser developers allow me to ignore the more user-hostile parts of the spec.

draw_down3• 10 years ago

Sometimes it's better to turn off for usability reasons, and the browser doesn't have a clue about when that's the case. For example when the page has its own autocompleter, which has more information available to it than the browser does.

A good example is the branch-switching widget on Github's repo page. Browser autocomplete is a major pain in the ass when trying to use this widget. The page can load all the branch names itself, but your dumbass browser is "helpfully" autocompleting a bunch of branch names that probably don't even exist anymore, or exist in other repos. Gee, thanks soooo much.

chrishacken• 10 years ago

" For example when the page has its own autocompleter"

Wouldn't that just override whatever values Chrome throws in there anyway? (If you're using JS.)

jasonlotito• 10 years ago

There are ways to resolve those situations properly as explained in the link being discussed.

Pxtl• 10 years ago

I've been trying to use the Facebook page on my phone since they've killed the FB Mobile web messenger and the amount the FB autocomplete and the Chrome autocomplete fight each other and mangle my text is spectacular.

serge2k• 10 years ago

I'd much rather have things like that broken then have to futz around with someones stupid login form that disabled password pasting and autocomplete.

michaelmior3• 10 years ago

I could argue that it's my website and I get to decide what features I want to be usable. And if you don't like that, then go visit someone else's site.

(This is not actually my personal stance, just playing devil's advocate.)

itp• 10 years ago

Except that on a very real level, a website is a collection of resources along with instructions about how to assemble them. This is like getting upset at someone for putting together a Lego set "wrong."

tajen• 10 years ago

Curious to see whether websites will start using DRM features for this purpose.

Also, as long as changing the User-Agent header is recognized by a jury as impersonation, I can imagine that some country with retarded lawmakers [1] could require that browsers display the website the way the website owner wanted it.

[1] a.k.a. where copyright owners are allowed many things over the citizen

raldi3• 10 years ago

You could argue that, but the user who owns the web browser has all the power in this situation. It's an arms race the website operator cannot win.

magicalist2• 10 years ago

I could argue that it's my website and I get to decide what features I want to be usable.

Sure, and you could also argue that it's your website so you'll decide if you want to use a self-signed certificate, or lots of popups, or auto-play video with audio. That doesn't mean the browser has to listen.

harikb• 10 years ago

I agree. I always hated sites that disable Paste, disable right-click or whatever.

yoo1I• 10 years ago

Coincidentally, Google Docs does that. It disables right-click for copy/paste and prompts you in a popup to install some stupid app to re-enable this functionality.

... or you know CTRL-C/CTRL-V, cause there isn't really a good reason to prevent you pasting with a mouse.

I really don't get that

bbarn• 10 years ago

I've had this bookmarklet for years on my toolbar, fixes all kinds of hijacks..

javascript:void(document.onmousedown=null);void(document.onclick=null);void(document.oncontextmenu=null)

wmil4• 10 years ago

Counter argument: Chrome doesn't ask you, and they don't provide any way for you to respect the standard behaviour.

If it breaks websites you use then your only option is to completely disable autocomplete.

tracker16• 10 years ago

I find that there's far more times I'd rather have autocomplete than have it actually disabled... I hate when sites force it disabled, when there's no real reason to, and as a user it's irritating.

The only time I find autofill annoying is sometimes (on my phone) lastpass will fly open at inopportune times, when entering something in a password field that's not really a password, etc.

tacone4• 10 years ago

The problem is simple: what is a login form? Browsers detect the login form from the presence of password fields and sometimes an email field. If you ever have an admin form were you can change the password of a user, you will get the autocomplete everytime, no matter what you do. You have to resort to JS. Also there are situations where you just don't want to give your users the choice (bank apps etc).

timv3• 10 years ago

This!

I have previously wasted so much time working around this browser behaviour.

The trick I use now is to add in a hidden (via CSS) pair on inputs earlier on the page, that do nothing. The browser fills those in, and leaves the real password admin fields empty.

tsieling• 10 years ago

Cool, we've created several forms re-used in the same browser for different people to gather public information. We now know never to use Chrome, since its developer assumptions trump our actual design needs.

groby_b• 10 years ago

Since you have direct control of the browser, the simplest answer would be to go to settings and turn off autocomplete entirely.

philliphaydon• 10 years ago

Autocomplete in chrome is one of its worst features. From a user and developer perspective.

MildlySerious2• 10 years ago

Flash. Cookies. Location. Autocomplete?

It's good to have a choice, but having to click my way through a dozen of these popups and fixed toolbars before having the content on my screen I desire is not the future I want.

aftbit• 10 years ago

Does anyone really still feel that Chrom(ium) is "your browser" anymore? It is just Google's way to exert their dominance on web standards and make paternal and self-serving decisions, all in the name of helping the "average" user.

As for extensions to allow customization, where's the extension that gives me back page actions (icons in the URL bar)? I know all the folks at Google are using shiny MBPs with billion-pixel displays, but I don't really like having 10 icons on the right of my URL bar just to show various status pages. :(

raldi3• 10 years ago

You can drag the right edge of your URL bar left and right to show or hide those icons.

Gracana• 10 years ago

Is there ever a reason to honor that setting?

matthewcford• 10 years ago

A valid reason is a search field, on a shared system where you do not want it to autofill with past searches.

wiredfool2• 10 years ago

  * One time password fields. 
  * Admin pages for dealing with users
  * CC virtual terminals
  * Any time that the data being collected is about a third party.

kuschku5• 10 years ago

If the site has its own autocomplete?

JoshTriplett• 10 years ago

The original motivation for autocomplete=off came back when Mozilla had a small market share and Firefox and Chrome didn't exist. Some major bank websites blocked Mozilla by User-Agent. When Mozilla and Mozilla users got in contact with those banks, the banks demanded the ability to block autocomplete for their login forms. Several times afterward, when people wanted to fix autocomplete, the banks had an effective veto with "we'll block you". At the time, Mozilla didn't have nearly enough market share to say "no, that's our users' decision".

See https://bugzilla.mozilla.org/show_bug.cgi?id=63961 for the history.

edoceo2• 10 years ago

This causes many problems for app devs to work around this broken policy. StackOverflow is full of silly tricks from field naming to odd JS. Wasting time

d4rti• 10 years ago

What's the use case for not allowing autocomplete?

CodeWriter235• 10 years ago

Getting 25% fewer users to continue through the funnel. https://news.ycombinator.com/item?id=11911434

micaeked• 10 years ago

A few devs posted their use cases here: https://bugs.chromium.org/p/chromium/issues/detail?id=587466

realityking• 10 years ago

I've had massive problems with it for CRUD apps. Whenever you created a new user it would fill in the values from the first user you created on that system. Annoying as hell.

The other problem - that we mostly managed to workaround - is that AngularJS and some browsers' autocomplete didn't go along very well.

winstonewert• 10 years ago

When you have your own javascript driven autocomplete that provides more accurate/context specific suggestions.

coderzach• 10 years ago

1) The default design of autocomplete makes your app look really bad.

2) There is an input for searching by name, email, etc. And you don't want it to auto fill with the users credentials.

vbcr• 10 years ago

Google's Search input field has autocomplete="off" setting. This is one of the popular use case I think.

wmil4• 10 years ago

A field named 'email' isn't necessarily for your email.

Apple has popularized the save field on edit model, so autofilling fields can potentially destroy data in a crud type app.

dimal• 10 years ago

If you have a field for the user to change their password, you don't want to autofill it with their current password.

snovv_crash• 10 years ago

OTPs. By definition they are different every time.

bcheung2• 10 years ago

If the app expects the value of the field to be blank because that is what it was set to, then Chrome auto fills it, but it doesn't generate onChange events. So the app never knows the form has a value.

MildlySerious2• 10 years ago

Not a use case, but Chrome bugs out when an input gets moved with CSS translate() and the autocomplete is open. The autocomplete stays in place unchanged while the input zooms off.

Even if that wasn't the case, a well design form element that animates (transition in a game) looks very different to a deafault-autocomplete I can't turn off.

This is taking away choice. No more.

edoceo2• 10 years ago

The webhook form on github has autocomplete=off. Chrome prefills the hook URL with github username and the secret with my password.

The browser is clearly doing the wrong thing.

zbowling• 10 years ago

I fully support the decision by Chrome. I hate when forms try and force it off and get me to type the same thing over and over. It's an abused attribute.

tetrep• 10 years ago

I see this as a good thing. Far better to streamline password management than to make it bumpy, encouraging users to use memorable passwords, which most likely will also be painfully weak.

It's a good and sane default.

wiredfool2• 10 years ago

I'm trying autocomplete='sudo-off' now. It's not really semantic, but it does get across my intention.

(in this case, a new user form designed for a current admin. Sometimes the site developer really does know more than the browser)

JungleGymSam3• 10 years ago

I think you mean "pseudo".

timv3• 10 years ago

No, he meant "sudo"

https://xkcd.com/149/

http://www.explainxkcd.com/wiki/index.php/149

CodeWriter235• 10 years ago

"We announced during the Chrome Dev Summit in 2015 that when Autofill is enabled we see 25% more forms submitted than when it's disabled [3]."

In other words, 25% more users will make it to the next stage of your conversion funnel if autofill is permitted.

Animats• 10 years ago

That's a reason to turn on autocomplete in your signup form, not to force it on in the browser.

CodeWriter235• 10 years ago

That would be a negative user experience, given the prevalence of legacy forms on the web. Example: "Why does this autocomplete feature fail most of the time?"

notatoad• 10 years ago

"and of you're using a form for something other than a conversion funnel, well screw you"

Someone1234• 10 years ago

I'm going to side with the Chrome team on this one. There's very few occasions when autocomplete being disabled makes sense, the vast majority are just developers dumping it in there because they want to make doubly-sure the user actually entered a field by hand (e.g. email addresses) and often for vaporous reasons like "Improve Data Quality," "Stop Spammers/Bots," and "Make sure the user enters the right data in the right box."

Ultimately if you want to assure data quality then use data or format validation, or verification (e.g. send an email with link). If you want to stop bots/spammers use captcha.

We did go through a period where people were "misusing" standard input boxes for other things and autocomplete would ruin that extra usage. But hopefully we've moved beyond turning an input box into a richtextbox using a complex array of hacks, and can now instead use things like Canvas.

PS - Hopefully they disable "smooth scroll" scripts next. So tired of having my scrolling ruined by "helpful" sites.

mrweasel• 10 years ago

There's very few occasions when autocomplete being disabled makes sense

True, perhaps. The point is that's not for Google to decide. In their example with CRM system, it's very possible that the developer did think about it, and decided that autocompletion would "help" the user enter wrong data.

Now Chrome forces you to be non-compliant to work-around to their "custom feature".

Chrome is increasingly encouraging developer behaviour that's reminiscent of Microsoft and Internet Explorer 6.

timdierks2• 10 years ago

It's not for the developer to decide any more than the browser. It's up to the user.

volatilitish2• 10 years ago

There are lots of examples.

I'll give one. A text input for a chat you're having with someone. It's very very offputting and irritating to have the browser constantly cluttering the UI with suggestions about what you might want to type in that chat box before you press enter.

gmazza3• 10 years ago

Message input field for chat/forum would typically be <textarea>. For example - have a look at reply page source right here, on HN.

And <textarea> doesn't auto-complete regardless of explicit options.

gkya4• 10 years ago

There's very few occasions when autocomplete being disabled makes sense

What are those (seriously, I can't think of any off the top of my head).

chillacy2• 10 years ago

I know of one from a previous project. We had a prompt that said "enter your home address" with JavaScript autocomplete using google location APIs. Unfortunately chrome would try to auto fill this box with a city name (not even the full address) and this auto fill prompt sat on top of the JS drop down.

MikeTV2• 10 years ago

In our user management portal, whenever tech support opens the Create New User or Reset User Password page Chrome helpfully fills their administrative password into the user's password field.

IanCal3• 10 years ago

Any search box where you want to hit a backend server and do typeahead searching.

Edit - for a good example, google use it on their search box.

tracker16• 10 years ago

The irony is when I have to hand-enter my email address, especially on my phone, I'm far more likely to mistype it and make a mistake... And on the receiving side, I'm sick of seeing emails for someone else.

koolba2• 10 years ago

As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.

Reminds me of the good old days of making things work with IE6.

Again, thanks to everyone for your comments. We look forward to continuing the conversation.

Sure you do. Then why is commenting closed?[1]

[1]: See the "Restricted- Only users with EditIssue permission may comment." box on the left pane.

md224• 10 years ago

Sure you do. Then why is commenting closed?

From the post:

All this said, we're still learning. So we would like to better understand your use cases for setting autocomplete=off. To have that conversation in a more focused manner, I've created a new bug: crbug.com/587466. We're going to try and keep that conversation focused and productive, so we want to avoid "+1s" and the like. I'll be closing this bug in the meantime.

Commenting is open at https://crbug.com/587466.

koolba2• 10 years ago

Ah! Well that's what I get for skimming through the post.

I stand by the IE6 comment though.

edibleEnergy• 10 years ago

'The semantic meaning' hack is bad for readability. You don't actually mean 'new-user-street-address' you mean 'do not autofill this input chrome.' The next developer in will assume the semantic meaning accomplishes something, and decorating your markup with things that may or may not do nothing seems is bad practice.

_Codemonkeyism• 10 years ago

Some years ago we had trouble with autocomplete. Browsers would fill in credit card details and customers would call us where we've got their credit card details from. Or they we're completed into a different website and people called us why we gave the other website the CC details.

donatj2• 10 years ago

I actually find this particularly annoying working for a service aimed at elementary schools.

Our user base is almost entirely shared desktops / Chromebooks in schools. Not all school admins are smart enough to disable password saving / autocomplete (not to mention not all schools have someone for this) so we see cases of a kids account getting misused because it was saved on some library desktop all the time.

Give users the option to opt out, but taking the power out of the app developers hands by default is short-sighted.

tsneed290• 10 years ago

We have a similar issue in the quality management space.

Multiple quality folks on a shop floor accessing a QMS from the same machine. If an IT admin forgets to disable password saving, compliance rules could be broken if one quality member has the ability to electronically sign a document using someone else's saved password.

mikeash3• 10 years ago

Why should app developers have the power by default? It sounds to me like you're arguing for that just because that happens to be what you have trouble with. But I'm sure we can find plenty of other people where having the default be the other way would work better.

Your actual problem is that your users can't change even the most basic settings, and you're not in a position to change it for them. I'm sure autocomplete isn't the first nor the last symptom you'll have due to this problem. Good defaults are important, but good defaults are about more than what works for shared desktops in schools with clueless IT people.

donatj2• 10 years ago

A platform the app developer can't secure isn't a good platform for a secure app.

It speaks negatively of the web over a native app for this to be disabled by default.

gmazza3• 10 years ago

What you raise is a valid concern, but letting websites decide on enabling/disabling auto-complete is solving it entirely wrong way around.

If local admin is incapable of configuring user accounts, how are websites supposed to figure out who is who, and which browser is on shared computer?

After all, if managing user accounts is too hard for said admin (or we are talking about a shared PC in a library, which doesn't have user accounts as a matter of principle) - just make browser always start in private/incognito mode on shared computer. It is as easy as adding command-line argument "--private-window" for firefox or "--temp-profile" for chrome. That's it. Window closed - autocomplete gone. Problem solved.

arenaninja4• 10 years ago

Assumes a competent, dedicated local admin is on staff. This is not the case at about 75% of the SMBs I've come into contact with over the past two years

kalleboo3• 10 years ago

Websites will always have the ability to disable auto-complete though. Just now it will be though a series of ever-increasingly insane hacks found on StackOverflow (culminating in a custom JavaScript textfield with broken accessibility/internationalization)

LionessLover2• 10 years ago

Quoting from the actual Google reply:

We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2]
In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.
As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.

If you would read what they actually wrote you would notice that - as usual - the headline does not even remotely catch the complexity of the problem.

djrogers3• 10 years ago

Not all school admins are smart enough to disable password saving

So how would allowing a small percentage of web apps to disable autocomplete resolve this? It only makes it slightly less painful for the websites where autocomplete is disabled - everywhere else you have the same problem. You're asking the wrong people to solve this for you here.

magicalist2• 10 years ago

Are there any browsers left that haven't long ignored autocomplete=off for password fields? Chrome did that some time ago, as did Safari and Firefox.

This change is for all input fields.

i336_• 10 years ago

This definitely warrants reporting on the followup bug that was listed at the end of the linked bug: https://bugs.chromium.org/p/chromium/issues/detail?id=587466

Arzh• 10 years ago

I was wondering why my Pizza Hut login process got a lot smoother.

avodonosov• 10 years ago

Horrible. There are cases when autocomplete="off" is necessary to improve user experience. It's sad that such policies are defined by people not familiar with web development enough to know such cases.

Also, some forms will become inconsistent when autocomplete="off" is ignored (radio button filled by autocomplete instead of the value specified by developer, but the related text input field is disabled as specified by developer).

Moreover, it's a standard. Everyone was complaining about Microsoft when it introduced non-standard HTML and Javascript semantics. Now Google does that.

michaelmior3• 10 years ago

Are there any cases which can't be handled by autocomplete="okay-google-really-off"?

Analemma_• 10 years ago

It'll be amusing if this creates an arms race where Google ignores more and more autocomplete values, until someone just makes an Apache/nginx extension which just gives them a random value.

IanCal3• 10 years ago

Turning it off in other browsers? What do other browsers do when they don't understand the setting? If any of the others say "well it doesn't say off, so let's leave autocomplete on" then you're a bit screwed.

skynetv2• 10 years ago

i love autocomplete and i hate when the page tries to turn it off for no logical reason. I have an extension installed that forces autocomplete on for everything.

gmazza3• 10 years ago

Good riddance. Now can we please start ignoring:

  onpaste="return false;"

rogerbinns2• 10 years ago

There is a chrome extension for that (NSFW name) https://chrome.google.com/webstore/detail/dont-fuck-with-pas...

artursapek• 10 years ago

Banking websites do this. I cannot stand it. Thanks.

darkstar999• 10 years ago

On that topic, how about the ability to disable manipulating of copied text (is there a name for ctrl+c injection?)

jrochkind13• 10 years ago

We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2] https://html.spec.whatwg.org/multipage/forms.html#autofill

Okay, aside from what you think about being unable to just turn off autocomplete, those semantic tabs actually sound super useful, and i hadn't known about them.

As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address".

Um, "new-user-street-address" does not appear in the list of recognized values from the WHATWG spec that was linked to above.

How do we find the list of values that Chrome actually recognizes and what they mean?

Am I missing it somewhere else? How does Chrome expect devs to use something completely un-doc'd?

timdierks2• 10 years ago

You elided the relevant sentence:

In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.

They're saying that they don't autofill when they see autocomplete values which Chrome doesn't recognize, so if you don't want autofill, they suggest you just put in a description of what this field is, which won't be recognized. The functionality is the same as if you put in autocomplete="foobarbazquux", but it's better-described.

jrochkind13• 10 years ago

Ah, thanks, I didn't do it on purpose, I was just confused. Because:

our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.

How is a value not allowed by the spec "valid" as they say? They're encouraging you to violate the spec to trigger chrome-specific behavior (can't really say what other browsers will do when spec is violated, can you?), really? Or does the spec say you're allowed to make up new values too? i don't _think_ so, but maybe I missed that part (not being sarcastic).

michaelmior3• 10 years ago

It was my understanding that currently Chrome doesn't support any special behaviour for custom values of the autocomplete attribute. I think they just want to get people used to this and probably start capturing data (via web crawls) of what values people actually use to decide what to implement in the future.

wnevets• 10 years ago

ignoring standards worked for IE.

merb• 10 years ago

Google's own Search field:

    <input class="gsfi" id="lst-ib" maxlength="2048" name="q" 
    autocomplete="off" title="Suche" type="text" value="" aria 
    label="Suche" aria-haspopup="false" role="combobox" aria   
    autocomplete="both" dir="ltr" spellcheck="false"
    style="border: none; padding: 0px; margin: 0px; height: 
    auto; width: 100%; position: absolute; z-index: 6; left:
    0px; outline: none; background: ....

oh....

autocomplete="off" and autocomplete="both" really strange.

xrstf• 10 years ago

One is `autocomplete`, the other is `aria-autocomplete`.

Scryptonite• 10 years ago

It's tough to say that Chrome made the right call, as I enjoy being able to (in theory) rely on browsers aiming to be standard compliant. The standard is there for a reason, no?

I noticed that the Chrome team also developed a feature called Threaded scrolling in an attempt to improve site UX, but instead (or additionally?) completely ruins the ability to rely on onscroll/onmousewheel events (let alone being able to trust the values pulled from scrollLeft/scrollTop using requestAnimationFrame or similar). This can be seen on these two GIFs, with threaded scrolling enabled (currently the default behavior): https://gfycat.com/DiligentHomelyIndianelephant and with threaded scrolling disabled (behind a chrome flag): https://gfycat.com/SlimDefinitiveErin

The same flag/feature is active on mobile Chrome as well, so the same effect can be seen. The only way to guarantee jank-free work with scroll position (for parallax or w/e) is to implement handling user-input-to-scroll-behavior entirely yourself, which is rather unfortunate imo.

You can play with this yourself: http://jsbin.com/mohehotupe/edit (might need to click "Run with JS" / or tick "Auto-run JS" to start the scroll-listening script)

My take on autocomplete is that the standard says it's something I can disable, so autocomplete="off" is simply something the browser should obey. I have no problems with users using extensions or taking "advantage" of a browser setting to "fix" websites they say have abused this attribute. But there are valid use cases for disabling autocomplete as other comments have mentioned, and all they have done is make it to where I just have to do autocomplete="sudo-off" and it "works". But what happens when other webmasters misuse the attribute again? Might as well just toss support for it if they really can't trust the page to do the right thing.

abalone• 10 years ago

It's not just Chrome. Safari[1], IE and even Firefox[2] haven't respected it either for quite some time.

[1] http://stackoverflow.com/questions/22636673/safari-saved-pas...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=956906

pbreit• 10 years ago

Probably best for the 99%. I suppose for the 1% they could consider a flag?

rocky1138• 10 years ago

Good idea. What if we include an attribute in the form itself. I propose "autocomplete" You can set it to "on" or "off" depending on your needs.

growt• 10 years ago

I think it is necessary for some fields to have autocomplete="off" for PCI compliance (login/password field if I remember correctly). So this creates the interesting situation where I should set autocomplete to something else so that chrome doesn't complete it, but that would result in a failed compliance check.

WildUtah2• 10 years ago

Yes. PCI is a silly substitute for actual security. But the alternative is that many banks and their partners will run with no security because bank executives as a class are firmly opposed to sharing authority with competent IT security people.

This is one cost of their class solidarity.

Dylan16807• 10 years ago

I have some pages with passwords but not usernames, and chrome keeps trying to treat it as a login, picking an arbitrary nearby field as username, and ignores all markup suggesting otherwise. It's on my todo list to figure out something that bypasses its stupidity, like setting it to a normal field with a weird font, as it's not necessary to prevent copying out of the field.

Jordrok• 10 years ago

This is one of the few cases where I'm actually in favor of Chrome's rogue behavior, though I think they're probably doing it for the wrong reasons. I've been annoyed one too many times by webpages that refuse to allow me to autofill login credentials from my browser, to the point where I had to keep a js bookmarklet to strip that attribute from every element on the page. I always hated that it took such a hacky solution to do something which is so simple, and resented sites that attempted to take that ability away from me.

So to me, any change which puts control back in the hands of the user is a good one. I suspect though that the motivation is mostly to "increase engagement" rather than to empower the user.

josteink• 10 years ago

Google Internet Explorer.

Might as well adopt the name now, rather than later.

zeta0134• 10 years ago

I've noticed that a great deal of secure websites will disable autofill in their username and password fields on purpose. For ages I've had a Chrome extension installed that disabled autofill=off to get around exactly that, and I believe I'll leave it enabled. I know better than to trust plain password auth anyway, and mostly use the feature to remember one-time passwords to things like forum sites that have the ridiculous policy of hiding plain URLs to non-registered users. (I will never understand what a forum gains by having a large number of users in their database who registered once to download that one attachment, then never came back again.)

Regardless of the intent, I think when you try to make decisions on behalf of your users, you're doing them a disservice. I mean, really, the security risk of autofill on password fields is that the user's passwords are now saved on their computer? I think users who need to utilize this feature and have it denied them will just end up typing the password into a word document named "Passwords.docx," and that's a heck of a lot less secure than Chrome's encrypted password store. Not that Chrome's implementation couldn't be better, but still.

WildUtah2• 10 years ago

Why use a Word document? I put all my security passwords—especially the ones that won't autoflll or that make me change them often—into a Google Docs spreadsheet online. That way I can get to my passwords from anywhere.

marktl• 10 years ago

Trusting users over developers will lead to less security overall. In this case it will make providing intranet access to employee owned devices a little less secure or less user friendly (by blocking chrome)

lucb1e• 10 years ago

Firefox has been doing this for quite some time now: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

gkoberger3• 10 years ago

Here's a huge reason why this is bad. Our company let's you set a "global password" to lock your site. Chrome was auto-filling the password site silently, and exposing people's personal passwords to their whole team when they saved. I understand wanting control, but... Sometimes this is horrible behavior.

acdha2• 10 years ago

Why isn't that a bug in your application? Unless you're building a password manager, passwords should never be shown to someone else. If you need the ability to let multiple people do things, they should still perform the action using their private credentials so you'd have accurate records for who initiated the action.

gkoberger3• 10 years ago

No, it's an outward facing password to preview non-live sites, like Shopify or Squarespace have. More of a beta code than a password.

marcosdumay• 10 years ago

Why don't you use, you know, a password field for entering that password?

gkoberger3• 10 years ago

We did, which caused the problem. (We had a "show password" option, but even if we didn't, it'd still be visible in the HTML)

JungleGymSam3• 10 years ago

As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.

Seems reasonable to me.

kuschku5• 10 years ago

Except, Google themselves now do "google-chrome-autocomplete-off" and "both" and similar values instead.

We just replicated the PHP or IE situation with mysqli_real_surely_this_time_it_works_escape_string or autocomplete="sudo-off".

dragonwriter10• 10 years ago

Except, Google themselves now do "google-chrome-autocomplete-off" and "both" and similar values instead.

That's clearly a suboptimal practice by Google's web team. Which doesn't make Google's Chrome team wrong, but maybe the latter should have a word with the former.

frandroid• 10 years ago

In cases where you really want to disable autofill

Dude, we've already told you.

bcheung2• 10 years ago

So many ugly hacks are needed as a consequence of this.

I know what I want my app to do better than you Chrome. Please don't purposely break the Internet.

When I try to do user management. I can't call the fields `username` or `password` because Chrome will attempt to autofill it with the saved user/pass from the login. So annoying. :(

Also, it doesn't trigger onChange events when it gets autofilled. :(

This breaks Angular because the field's value is different from what Angular thinks the field's value is.

Kiro• 10 years ago

Isn't a chat a better and more common example than a CRM system? You don't want to autocomplete your old chat messages.

xemdetia• 10 years ago

It feels like the solution here is to have a serious-business flag for chrome like phabricator does. Is the browser working for me or is it just helping me work for someone else? That seems to be the real intent problem here. I feel for all the CRM types and data entry people that are going to struggle with this. The user may decide that they don't want autocomplete for a page but they may not be sophisticated enough to turn it off in a meaningful way, or for a particular site.

I still think it's really troublesome that it invents a user-side data store of potentially sensitive data that they really had no say in.

djcapelis• 10 years ago

Good. It's taken far too long for user agents and web standard to remember that the intent of a user agent is to be an agent for a user, not something that an external server can dictate with pixel perfect precision.

vmarsy• 10 years ago

I'm not very familiar with autocomplete behavior, but does this work across domains? on hidden fields?

Would this help <malicious website> or even <legit website but with malicious tracking intents> to extract information without my consent?

leepowers• 10 years ago

How is this going to work with honeypot fields? Chrome will autocomplete hidden fields like this:

    <div style="display: none;">
        <input type="text" name="phone">
    </div>

Where "phone" is the honeypot field. Not shown in-browser, so usually only a bot will fill out the honeypot field, sending a strong signal that the form is an automated/spam request.

Of course, autofill messes this up. So the more correct implementation is to turn it off:

    <div style="display: none;">
        <input type="text" name="phone" autocomplete="off">
    </div>

But if an autofill of "off" is ignored this technique will no longer work, as the user's browser will fill in the honeypot field.

Strom• 10 years ago

Based on the OP you would use:

    <div style="display: none;">
        <input type="text" name="phone" autocomplete="honey-phone">
    </div>

The way I understand it, it's not that autocomplete can't be turned off, it's that "off" no longer turns it off. You can still turn it off in plenty of other ways.

tracker16• 10 years ago

Another possibility would be to add two fields dynamically via JS at load, the first populated at load with a timestamp when the form was loaded... then add onkeyup/onfocus/onclick events for the other form fields, and when triggered populate the second field with the current timestamp.

From there, you can compare the numbers, offset from the current time, and do other checks. I mean, you might want to allow for up to an hour of drift, but most people won't sit on a page for an hour then hit submit.

Though it would be circumvented easy enough, if it's custom, would worry less about it.

Also...

    <div style="display: none;">
      <input type="text" name="phone" autocomplete="section-honeypot nofill" />
    </div>

wvenable• 10 years ago

It's ok, most bots are smart enough to avoid invisible fields. This probably hasn't worked in 5 years.

zimbatm2• 10 years ago

If you follow the link to the next discussion it quickly becomes pretty clear that it's a bad idea: https://bugs.chromium.org/p/chromium/issues/detail?id=587466

Anyone who has to fill forms for other people is going to end up putting his own personal information into the fields by mistake.

zimbatm2• 10 years ago

The one that I wouldn't mind changing is when the site somehow blocks pasting a password into the field. Yes, I'm not typing it because I use a password manager thank you very much!

grandalf• 10 years ago

Google isn't the new Microsoft, it's the new Halliburton.

xg152• 10 years ago

The rationale for ignoring autocomplete=off makes sense to me. What I don't understand at all is the suggested "workaround" for disabling autocomplete:

In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. [...] As an example, if you have an address input field [...], you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.

So essentially they encourage authors to make up random, nonstandard values for the attribute that may or may not do what the author is hoping for.

I don't see what this will archieve except making the autocomplete attribute a pain to use in practice.

(Which might be what the Chrome team intends, but even then, a more straight-forward and more honest way would be deprecation.)

djrogers3• 10 years ago

they encourage authors to make up random, nonstandard values for the attribute

No, they are encouraging you to give more meaning to your fields. For the example given of a CRM app, using customer_email_address as the input field makes much more sense than using a standard value for email address, as the two fields are asking for different things: The latter always wants your email address, whereas the former wants the relevant email address for the record you're viewing/editing.

xg152• 10 years ago

But there is no guarantee all sites will use the same values or even give the values the same meaning: One might write "customer_email_address", another "e-mail-address-of-customer". A third one has separate input fields for the parts before and after the "@" and uses "email-address-name" and "email-address-host" respectively...

So in the end, if everyone followed the advice and used "semantic" values, this would likely lead to the same problems that HTML already had with semantic class names, rel values and meta tags. The discussions about them fill mailing list archives. I don't see why all this should be repeated, even more so as the problem of semantically annotating your elements is already solved.

But in this case it's even weirder as that was presented as a way to tell Chrome "please don't autocomplete". So if that's the real motivation, then sites are likely to just put some variant of "really-really-off", or just random strings in it without any regard to "semantics".

ComodoHacker• 10 years ago

In the WHATWG standard, we defined a series of new autocomplete values

  ...
  "language"
  "bday"
  "bday-day"
  "bday-month"
  "bday-year"
  "sex"
  "url"
  "photo"

I can't resist the feeling these were specifically developed by the User Data Mining department.

djrogers3• 10 years ago

Chrome, IE11[1], and Firefox[2] all do this, and have for a while.

[1] IE11 does not support the attribute at all http://lists.w3.org/Archives/Public/public-webapps/2014JanMa...

[2] Firefox ignores it too https://bugzilla.mozilla.org/show_bug.cgi?id=956906

dragonwriter10• 10 years ago

Both of those apply just to ignoring autocomplete settings for password management, not other input fields.

That's different from Chrome not giving effect to autocomplete=off for any fields.

jmcnevin• 10 years ago

Would you ever want autocomplete on, say, a field where you're inputting a 2FA response? Probably not, since any suggestions would be useless.

I find the workaround of "just put some other random bullshit for the value" hilarious. And once developers start over-abusing that as well (they will), then what's the plan?

kevin_b_er• 10 years ago

One of the commenters on the linked bug to discuss valid use cases for autocomplete=off hits a wonderful nail on the head:

Actually there is a famous site called http://www.google.com they use autocomplete="off" for their search form since every time you visit the site you want to search something completly different.

geuis• 10 years ago

I wish I had been able to find this a few weeks ago. Was working on a modified login feature where the autocomplete behavior was actually a hinderance to a UX improvement we were working on.

byuu• 10 years ago

Not making a comment either way on whether they should be doing this, but ... I think we all know what's going to come next :(

    //add random number to stop Chrome from disabling autocomplete
    //--number is stripped off in form processing routine
    print "Address: <input type='text' name='address--" . rand() . "'>";

tacone4• 10 years ago

How long before somebody uses that to guess your physical address by creating a page with input field named 'address' and so on just to read their values with JS?

aphextron• 10 years ago

The problem is you can't read autofill values with JS. This leads to a horrible experience for users when you have say an Angular form that gets autofilled and they click submit and it tells them the form is missing data.

angry-hacker• 10 years ago

But would it be possible to send the values using ajax to server side?

tacone4• 10 years ago

Disappointing. I don't use Chrome, so for me it's difficult to even believe such thing is possible

mindcrime• 10 years ago

For the love of FSM, why is it that browser vendors are always so f%!#ng arrogant?? It's not just Chrome, we've seen this attitude from Firefox devs before as well: "fuck you, we know more about what you meant than you do".

I really wish somebody would fork either Chromium or Firefox and commit to delivering a browser that just fully, completely and accurately implements the various specifications, instead of trying to "improve" them like this.

Nitramp• 10 years ago

I wrote this extension a long time back: https://chrome.google.com/webstore/detail/docomplete/onlplld...

It removes "autocomplete[off]" from all input elements.

carn174s• 10 years ago

Pretty sure that Satan's minions invented auto-complete as a vector for side channel crypto vulnerabilities.

jrochkind13• 10 years ago

The weird thing is, `autocomplete=off` _does_ seem to have the intended effect on my Chrome. OSX 50.0.2661.102. Huh? Was this change made in a later version I haven't gotten yet?

“autocomplete=off is ignored on non-login input elements”

Related Stories