
“autocomplete=off is ignored on non-login input elements” - wmil
https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164
======
raldi
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]|
        +---------------------------------------+

~~~
draw_down
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.

~~~
serge2k
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.

~~~
tracker1
Man, is that annoying, or login forms that are in a dynamic dialog and/or
ajax-login out of band instead of a post, so that it doesn't offer a save
option... I mean, I tend to use LastPass over the built-in manager, just the
same, it gets annoying when sites work extra hard to subvert those things that
make actually using the web easier.

Along the same lines is one of the reasons I actually like
OAuth/OpenID/OpenAuth logins, etc... simply that I can avoid yet another login
that I only use on one site, with yet another password, that I generate and
won't remember anyway.

------
Someone1234
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.

~~~
gkya
> 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).

~~~
chillacy
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.

~~~
gkya
Wouldn't making it a textarea w/ rows=1 work? AFAIK textarea is not completed.

~~~
kalleboo
So we're back to hacks to replicate a feature that browser developers have
decided to ignore? Gotta love web technology.

If "just use a textarea" is a valid solution, why did Google even bother not
honoring autocomplete?

~~~
gkya
Well, the web technology is a pile of sh.t and in this case with the textarea
you don't put your hands as deep in to is as you'd with the text input. That's
how I interact with the web technology.

~~~
kalleboo
It's just amusing, that's all.

Prediction for the future:

1\. Google implements auto-complete for one-line textareas

2\. Web developers create textareas with 2 lines but hide the bottom line with
CSS and disable the return key

3\. Something so diabolical even I can't think of it

------
merb
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
One is `autocomplete`, the other is `aria-autocomplete`.

------
abalone
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...](http://stackoverflow.com/questions/22636673/safari-saved-passwords-
are-overriding-autocomplete-off-in-forms)

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

------
avodonosov
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.

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

~~~
Analemma_
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.

~~~
HappyTypist
Chrome 60 will now calculate the entropy of the value, and if it appears to
contain more entropy than typical strings it will ignore the value and whack
the programmer on the head.

------
donatj
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.

~~~
gmazza
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.

~~~
arenaninja
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

~~~
acdha
Modern operating systems have a guest mode which doesn't preserve state across
sessions - if they cannot manage something this easy, everyone should be using
a guest login.

------
gmazza
Good riddance. Now can we please start ignoring:

    
    
      onpaste="return false;"

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

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

~~~
rogerbinns
It is like they want to prevent people from using password managers and strong
lengthy passwords!

~~~
josho
In some cases because their legacy systems can't support long passwords. I
know my previous bank was restricted to 6 digits (maybe even just 4). Their
solution was to add in those annoying security questions like "What was your
first dog's name". Sigh.

~~~
roywiggins
I use Diceware for those things, in case I have to use them over the phone.
"My dog's name is effervescent mandible egg voldemort; my mother's maiden name
is regent utterly busted harpy"

------
leepowers
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.

~~~
tracker1
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>

------
jaitsu
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
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
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.

~~~
dragonwriter
> Fix the standard

The standard is that autocomplete attribute can be used to _hint_ to the user-
agent how to apply any autocomplete functionality it has.

The standard is _not_ that the UA must provide autocompletion when it is "on",
or must not do so when it is "off".

So, I don't see any problem with the standard and Chrome's behavior.

~~~
kuschku
Actually, the standard says that "on" is a MAY, but "off" is a SHOULD.

~~~
dragonwriter
Yes, and neither is a MUST.

------
xg15
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.)

~~~
djrogers
> 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.

~~~
xg15
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".

------
gkoberger
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.

~~~
acdha
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.

~~~
gkoberger
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.

------
zeta0134
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.

~~~
WildUtah
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.

------
jrochkind1
> 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](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?

~~~
timdierks
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.

~~~
jrochkind1
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).

------
zbowling
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.

------
_Codemonkeyism
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.

------
growt
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.

~~~
WildUtah
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.

------
edoceo
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
What's the use case for not allowing autocomplete?

~~~
CodeWriter23
Getting 25% fewer users to continue through the funnel.
[https://news.ycombinator.com/item?id=11911434](https://news.ycombinator.com/item?id=11911434)

~~~
arenaninja
Very nice, except when you have something that is explicitly not a conversion
funnel. Admin functionality being a big one

~~~
CodeWriter23
This is the use case where the web page should not interfere, thereby enabling
the user to use their password manager. You can't even log in to eBay using
1Password any more. That's ridiculous.

Perhaps what is needed is autocomplete="secure" where the browser will only
autocomplete after challenging the user for a master password.

~~~
__jal
I used to solve this "security" feature by patching the Safari binary to
ignore the attribute. Became too much of a hassle to chase that, but I
seriously resent site developers who think they know better than I how I
"should" be entering data on my machine.

Seriously - a number of the complaints on both sides of the issue in this
thread point to this. Running a lab and have a problem with autocomplete
remembering passwords? That's should be a site-specific setting. Have a
physical issue with typing, and use assistive software? The browser should
have a setting to get out of the %$&^@*% way. Run your own machine securely
(by whatever standards you choose to judge that)? It shouldn't be eBay's, or
Apple's, or Google's decision how you choose to type your password.

While I'm ranting, I'm seriously sick of a particular strain of arrogance
mixed with refusal to take responsibility that emerges in these discussions. I
recently had a discussion where a UX person confidently told me that they did,
in fact, know better than I on a similar topic. OK, fine; here's a use case in
which it seems that you're wrong. "Well, we can't cover every case; we have to
plan for the 80% scenarios".

You know my needs better than I, but refuse to take responsibility when you're
wrong? Sounds like a good time to show a bit of humility and allow the user
you apparently think so little of to make a choice.

~~~
arenaninja
I come off the opposite end, where this browser thinks it knows the data I
want to enter better than I do. It doesn't. Neither do developers. I just want
to use my browser plugin and ignore them both.

------
byuu
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() . "'>";

------
koolba
> 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
> 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](https://crbug.com/587466).

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

I stand by the IE6 comment though.

------
jmcnevin
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?

------
wiredfool
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)

~~~
JungleGymSam
I think you mean "pseudo".

~~~
timv
No, he meant "sudo"

[https://xkcd.com/149/](https://xkcd.com/149/)

[http://www.explainxkcd.com/wiki/index.php/149](http://www.explainxkcd.com/wiki/index.php/149)

~~~
JungleGymSam
Seems like a stretch of a joke.

~~~
Sylos
It would make more sense, if you were familiar with the Unix command line.
Pretty much whenever something tells you "Permission denied", you just retype
the same command with "sudo" before it and then it does what you want. And
yeah, that definitely happens often enough to be a running joke among Unix
users.

------
zimbatm
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](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.

------
kevin_b_er
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](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.

------
Dylan16807
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.

------
frandroid
> In cases where you really want to disable autofill

Dude, we've already told you.

------
Scryptonite
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](https://gfycat.com/DiligentHomelyIndianelephant)
and with threaded scrolling disabled (behind a chrome flag):
[https://gfycat.com/SlimDefinitiveErin](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](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.

------
marktl
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)

------
tetrep
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.

------
bcheung
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.

------
tacone
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
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.

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

------
JungleGymSam
> 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.

~~~
kuschku
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".

~~~
dragonwriter
> 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.

~~~
kuschku
Well, there’s no alternative.

You don’t want the Google search box, or the hidden textfield in Google Docs,
or so, to autocomplete.

~~~
dragonwriter
> Well, there’s no alternative.

Sure, there is. You could do a meaningful semantic autocomplete tag that isn't
one of the recognized ones, rather than a variant of "no, really, don't
autocomplete this". (Actually, "body" is probably not a bad practice, but the
other one was.)

------
Jordrok
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.

------
CodeWriter23
"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
That's a reason to turn on autocomplete in your signup form, not to force it
on in the browser.

~~~
CodeWriter23
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?"

------
vmarsy
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?

------
xemdetia
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.

------
lucb1e
Firefox has been doing this for quite some time now:
[https://bugzilla.mozilla.org/show_bug.cgi?id=956906](https://bugzilla.mozilla.org/show_bug.cgi?id=956906)

------
zimbatm
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!

------
djrogers
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...](http://lists.w3.org/Archives/Public/public-
webapps/2014JanMar/0015.html)

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

~~~
dragonwriter
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.

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

------
mindcrime
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.

------
ComodoHacker
>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.

------
Nitramp
I wrote this extension a long time back:
[https://chrome.google.com/webstore/detail/docomplete/onlplld...](https://chrome.google.com/webstore/detail/docomplete/onlplldgmkgpoangfokimmikjheamnfb?hl=en)

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

------
djcapelis
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.

------
jrochkind1
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?

------
geuis
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.

------
skynetv2
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.

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

------
Gracana
Is there ever a reason to honor that setting?

~~~
wiredfool

      * 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.

------
wnevets
ignoring standards worked for IE.

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

~~~
rocky1138
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.

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

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

------
josteink
Google Internet Explorer.

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

