A few years ago, I left a $1000 tip at the restaurant up the street because Chrome filled out the tip field with my zip code (which thankfully merely defaulted to max $1000 instead). The tip field was off-screen, and the ordering software didn't have a confirmation screen, just a "we just charged your card $X amount" screen, which made my eyes boggle.<p>EDIT: Looking at the original March 17th, 2015 bug, it would have been at exactly around that time...In fact, checking my emails, this happened on March 18th, 2015. I had ordered from them several times before this with no problems (they used "chownow.com" for their ordering backend).
As I had already commented on the issue, it completely breaks Germany's main train ticket selling website:<p><a href="https://i.imgur.com/BjYTgSn.png" rel="nofollow">https://i.imgur.com/BjYTgSn.png</a><p>They have tagged the field as autocomplete=off but Chrome just doesn't care.<p>Also see this linked issue where they collected valid use cases for autocomplete=off. They just seem to ignore 452 use cases (I can't comment on the quality of them, I did not read any).<p><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=587466" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=587466</a>
This has turned into a sad chicken-race between Google and developers, with lots of innovative workarounds on Stackoverflow.<p>Their tactic of overruling web developers doesn't work, it only make things more complicated for everyone, since many of the workarounds have other negative side-effects.<p><a href="https://stackoverflow.com/questions/12374442/chrome-ignores-autocomplete-off" rel="nofollow">https://stackoverflow.com/questions/12374442/chrome-ignores-...</a><p><pre><code> ## Example 1
For a reliable workaround, you can add this code to your layout page:
<div style="display: none;">
<input type="text" id="PreventChromeAutocomplete"
name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
Chrome respects autocomplete=off only when there is at least
one other input element in the form with any other autocomplete value.
## Example 2
Simply make your input readonly, and on focus, remove it. This is a very
simple approach and browsers will not populate readonly inputs.
Therefore, this method is accepted and will never be overwritten by
future browser updates.
<input type="text" onfocus="this.removeAttribute('readonly');" readonly />
Style your input accordingly so that it does not look like a readonly input.
## Example 3
Tell Chrome that this is a new password input and it won't provide
old ones as autocomplete suggestions:
<input type="password" name="password" autocomplete="new-password"></code></pre>
Because other people here are throwing in their frustrations, I will at least add that on the flip side I have been frustrated by sites that attempt to disable autofill for illegitimate reasons, like attempting to disallow password managers. I think I understand where this is coming from.<p>On the other hand, I, too, have been bit by this at least once, in the past. I think it was easier to just disable it at that time, but IIRC, the solution we landed on was to not use form controls at all but switch said text controls over to use content-editable elements. In our case it made sense, since it was not a form at all. My memory could be a bit hazy here, though.<p>(I do not work on Chrome or use Chrome at home, but as disclosure I do currently work at Google.)
Setting aside the merits/lack-thereof of this particular decision, Chromium ignoring established web standards like this is especially dangerous as we're trending towards a world where 1) Chromium itself powers the most popular browser in the world by an increasingly unhealthy margin, and 2) even competing browsers are increasingly becoming skins on top of Chromium.<p>We are becoming more and more reliant on the developers of Chromium to be steadfast stewards of the standardization process. Their massive influence means that any deviation from actual web standards on their part will inevitably create a new and conflicting de-facto standard that will create decades of lasting damage and irreversible tech debt for the entire web (eventually leading to a repeat of the IE6 dark ages).<p>Decisions like this demonstrate an utter disregard for the crucial role Chromium plays in the web standardization process, and jeopardizes the entire ecosystem.
I ran into this last week (with LastPass, not Chrome - this seems to be a common practice):<p>I have a form where users enter information about their suppliers (I make restaurant management software). This includes a field for the contact email address, which LastPass was autofilling the email address the user used to log in. This happened silently, quickly enough that users wouldn't notice it on page transition, and would <i>overwrite the initial value</i>. Even with autocomplete=off.<p>This was a DATA LOSS bug - users would load the page, make a few changes, save, and not notice that they'd lost the email address they'd stored for the supplier. Fortunately LP has a method to force disabling of autofill (data-lpignore=on), but this could have all been avoided if they'd <i>followed the spec I was relying on</i>. I still don't know if some other password manager, maybe built in to Firefox or something, will make the same mistake, haven't had time to check yet.
As a user, Chrome's autocomplete went down the drain for me once they started to fill all fields at once. I tried to autocomplete one field and often chrome filled the other fields with unfitting data. This happened so often that I started to manually complete fields even if autocomplete was available. I still miss the good old times[tm] of single-field autocomplete...<p>(And for the record: As a developer, I have been bitten by Chrome ignoring autocomplete="off" as well.)
I guess this will lead to a horrible coding style where instead of having this in the form:<p><pre><code> <input name="email">
</code></pre>
We will see stuff like this:<p><pre><code> <input name="16fkr9547kancot944128sddfksdf934998aafccugt75">
</code></pre>
Where developers use some type of abstraction that generates a random id for each field and then assigns it to the original value server side or in javascript.<p>Just like they already randomise asset filenames to avoid caching.
Curious as to the global business impact this has had. I personally have spent at least a dozen hours debugging forms and trying to disable autocomplete/autofill on my kiosk-based applications. How many development hours collectively have been wasted on this unilateral decision.<p>I have not been this frustrated since the days of writing css for ie6, and at least back then the devs response was more "sorry its our rendering engine" and not battre just saying GFY seemingly out of disdain.<p>I try to be as free-market as possible but I sure wish that the w3c had some teeth when it came to things like this.
Btw, at <a href="http://google.com" rel="nofollow">http://google.com</a>, this is what they have for the search field:<p><input class="..." maxlength="2048" name="q" type="text" jsaction="..." aria-autocomplete="both" aria-haspopup="false" autocapitalize="off" autocomplete="off" autocorrect="off" role="combobox" spellcheck="false" title="Search" value="" aria-label="Search" data-ved="...">
<i>Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off"</i><p>Is it “extreme” now for a computer to do what the user wants and not what a random Google employee wants? How does this differ from malware?
The way I see it, autofill off should mean off and if I click the icon in the address bar to bring up, well, let’s call it “quick access to per-site settings” then maybe I could override it for a specific page load or site, like you can Flash, etc.? This per-site configuration is starting to become “normal” given iOS 13 does the same in Safari for permissions, content blocking, automatic reader mode, etc. It would make sense that the default is “follow the HTML5 spec” but you could put a notice in the address bar if you really felt otherwise...?<p>Safari does a much better job by only filling visible form fields, I think (though it too has a tendency to put my address both in Line 1 and Line 3, which is annoying...).
Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c19" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=914451...</a><p><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=468153...</a>
Firefox used to ignore autocomplete="off" until relatively recently. I'm sick of sites thinking they know better than me -- like those who don't let me paste in the password field. While I understand the good use cases for this attribute, given the binary choice I would rather have it ignored.
The weird thing is that there's other teams within Google who offer autocomplete libraries that simply don't work because Chrome overlays it's own autocomplete on top.<p>The maps team seems to have given up on trying to resolve that.<p>Chrome team have made a judgement that autocomplete is required and no-one - not even other teams within Google are allowed to override that functionality.<p>It's weird.
Relevant reply from a Googler seems to be this: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=914451...</a><p>by battre@google.com<p>... which doesn't read at all to me like a "rogue dev" and more like a shared sentiment inside the Chrome team that autocomplete=off should be ignored.<p>At least, if there is a direct spec violation that breaks all kinds of applications and the answer your hear is "oh well, we're working on giving the user more options and improving our algorithm", that's not exactly encouraging.
It's odd that the linked bug report references and complains about W3C specs when browser/HTML specs have been coming from WHATWG for well over ten years now. W3C has ceased publishing HTML with W3C HTML 5.2 in 2017, and has announced an intent to merely publish WHATWG snapshots going forward; so far, I'm not aware of any actual work under this model by W3C.<p>But OTOH that Chromium interprets form field names heuristically to enable auto-autocomplete is worrying, and reflects poorly on the whole "standardization" process by WHATWG.
It's really frustrating to have to work around this with hit or miss hidden inputs and such.<p>So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text.<p>Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field.
I do not get from where it comes that it is a rogue developer. I have worked in many companies where developers make mistakes. And, it is always the ways of working, giving more priority to features than quality, and similar cultural attributes of the company at fault.<p>The only time I saw this being a rogue developer was a commit and run done by a guy on his last day.<p>It is easy to blame one person when actually is a systemic failure that needs to be addressed at the company level.
I run a site with a normal login/password, but which maintains passwords for other systems. It's pretty frustrating when the internal external usernames are autofilled with the username from our site. It confuses the user, suggesting that the username from the external site should be the same as our own.
I was using Google Places' address auto-complete on a CRM, and most users loved it. Chrome's behavior completely broke this functionality by overlaying their auto-fill on top of Google Places suggestions, with no sane way to disable it. We decided to stop using address auto-complete and force our customers to type the address fields instead.<p>Ironically, we were paying Google a few thousand dollars per month for this, so they are not getting our revenue as a direct consequence of Chrome's behavior.
I'm not sure who Chrome think they're helping. We get many, many users contacting our support team because of this feature / bug on <a href="https://www.openrent.co.uk" rel="nofollow">https://www.openrent.co.uk</a>.<p>It's frustrating, we've used workarounds, which then stop working and reports come flooding in again. It's crazy to me that the Chrome team think this is better for users, and that there isn't a more intelligent workaround for sites abusing autocomplete=off.
The Chrome dev team have implemented autocomplete the way they think it should work, not the way web developers want.<p>You cannot switch off Chrome's handling of autocomplete, thus any other autocomplete implementation will be overwritten by Chrome's handling.<p>Chrome team feel they know best.
Or line of business applications which (when rendered with Chrome) wants me to pick from my credit cards when I enter a certain field which has nothing to do with credit cards. I think it depends on the field name, but there seems to be a very loose correlation.
> This causes some problems, e.g. in <input type="text" name="name">, the "name" can refer to different concepts (a person's name or the name of a spare part).<p>Maybe I need context, but I don't understand why they're trying to 'guess' context around 'name' and trying to autofill something - either a spare part or a person's name.<p>Doesn't "name='name'" indicate that it should refill with the previously filled value of field named 'named' on that same page/document/url? Why are they trying to add algorithmic complexity on to already existing stuff?<p><input --chrome-type="name"/><p>This might make more sense, no? Let chrome try to determine a 'name' based on whatever logic they want.
There's a major security flaw with auto-fill when it comes to passwords. Sure, it's hidden on screen, but you only have to change the password box's type, so it isn't "type='password'" and it is revealed. This only takes a matter of seconds.<p>Chrome should remove the password if there is any attempt to change that form object.<p>This flaw has been there for years, it's actually handy if I'm not sure what the password is.
>>> - How to trigger the hiding? - right mouse button menu or (more likely) something in the drop down? where would we put that? ...<p>Mobiles notoriously don't have mouse buttons, so any UI relying on right-click will not be usable there.<p>It's odd that Google is considering mouse-based workarounds in all considered solutions, as if unaware of that. or maybe Chromium is only the desktop browser?
This position seems at odds with a recently opened WHATWG issue.<p><a href="https://github.com/whatwg/html/issues/4986" rel="nofollow">https://github.com/whatwg/html/issues/4986</a>
> if you add an <input type="hidden" autocomplete="username" name="does_not_matter" value="{the actual username}"> before your current-password and new-password fields, Chrome should get it right<p>I can't believe that this suggested hack is coming from google.<p><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c63" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=914451...</a>
>
Comment 66 by battre@google.com on Tue, Oct 8, 2019, 3:48 AM CDT (5 days ago)
- Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off" and "never honor autocomplete=off") are good<p><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=914451...</a><p>We're in for the Long haul on this one.
Discussion about a demo of the issue...<p><a href="https://news.ycombinator.com/item?id=13329525" rel="nofollow">https://news.ycombinator.com/item?id=13329525</a>
If you look at the chrome sources you can find this flag:<p>const char kAutofillOffNoServerDataDescription[] =
"Disables Autofill for fields with autocomplete off that have no "
"crowd-sourced evidence that Autofill would be helpful.";<p>So, at least in a company, this should work to avoid autocomplete making corporate apps unusable.<p>another thing that seems to work for me, is adding role="combobox" along with autocomplete="off"
title is wrong, the spec is not ignored.
spec says:
"
When an element’s autofill field name is "off", the user agent should not remember the control’s data, and should not offer past values to the user.
"<p>please note that it uses "should", not "must". these words have precise definition in specs, see RFC2119:<p>"
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
"<p>one may argue whether chrome has valid reasons or not, but saying they ignore it is incorrect.
Does Chromium not have anyone doing QA or acceptance criteria? A rogue dev lead could make whatever feature they want, but there should be a robust process of testing by many people before the feature makes it in to a production build.
I hat to fight with browser autocomplete in Kibana main search bar.
On the other hand I guess it is the same as right mouse button - I don't allow any site to capture that event since some abuse it.
I use autocomplete="x" and it seems to work for my apps.<p>Both Twilio and NameCheap seem to have login that defeat autocomplete in a nice way. Haven't investigate their tricks
> This has turned into a sad tit-for-tat between developers and Chrome, where no-one is winning.<p>Not the kind of relationship you want to build with an army of advocates
I would love it if someone explained how 'autocomplete=off' can lead to abuse of some kind. It seems to reduce the potential for security leaks.
Is "ignoring the specification" an extreme, now?<p>Are we seriously expected to entertain this mess?<p>So glad I switched to Firefox all those years ago.
There was a time when IE was the dominant browser, and happily did whatever they wanted to.<p>That was arguably better, because at least they acted predictably. Chrome has been continually altering how autocomplete is handled in the last 5 or 6 major releases
Thank you chrome, for recognizing that the USER is what matters, not the website developer. Websites started blocking legitimate uses of autocomplete, and that makes the web less secure. As a user I sincerely hope that "autocomplete=off" dies just like the blink tag, as it is user hostile.