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.
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).
This has a lot of really serious implications. I built a form for a charity that allowed users to buy a subscription but include an additional donation amount. Chrome was sometimes filling that field with the two-digit year. The charity got a lot of complaints and it ruined the trust relationship with the donors who didn't understand what was happening and thought it was intentional.
I wonder how much the [1] hiding of scrollbars and [2] UIs with excessive amounts of whitespace, increasing the need to scroll also contributed to you making this error.
We have trouble in our org with autofill on our New Customer forms. Depending on the browser it can be very difficult to remove the saved autocomplete values.
They have tagged the field as autocomplete=off but Chrome just doesn't care.
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).
Finally i know why this happens only in Chromium. This irritates me for quite some time now...
Seems that Chromium based browsers aren't favorable any more:
Tracking, Bugs, uBlock extension is flagged, Manifestv3, etc.
But Firefox has the same problem since it ships with Pocket and other sync stuff. I know that they really do care but they have problems of their own which really make me think which browser to use. The actual situation right now is very frustrating...
In general, I don't like software defaulting to convoluted "grandpa-friendly" behavior instead of the simple, no-bullshit behavior. Moreover, if you want the simple, sane behavior you're a weirdo and need to justify yourself.
Another example of this is chrome hiding "trivial" parts of the URL. i.e. any subdomain that coincides with "www" or "m".
I'm guessing chrome ignores, it because people often place the option when they shouldn't. I don't understand why browsers can't simply respect setting and perhaps provide option for the user to modify behavior per site per field with ability to save. They could go even step further and do what Opera used to do i.e. provide same defaults for most popular sites.
This has turned into a sad chicken-race between Google and developers, with lots of innovative workarounds on Stackoverflow.
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.
## 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">
Preach. Them changing the rules and overriding the usage of this attribute is ridiculously stupid in the first place. HTML attributes are there for a reason, developers are supposed to be able to use them and they are supposed to work as expected. But in order to push their password management and form filling functionality, they just give everyone a finger.
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.
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.
(I do not work on Chrome or use Chrome at home, but as disclosure I do currently work at Google.)
I think we need a way to disable features only for those developers that abuse them. Like uMatrix but built-in and with rules being supplied automatically as ad blocking lists are.
You autocomplete=off a password field? That attribute won't have an effect on your site anymore.
You auto-play videos when the user doesn't expect it? What videos? The web doesn't support videos – as far as you are concerned.
Scroll hijacking? I hope you used progressive enhancement because you just lost your Javascript privileges.
Disabling autocomplete is so incredibly frustrating that I ran an extension in Safari to remove the off tag from sites. Of course I want to use KeyChain, the whole point is that touch based ID is more secure.
We recently had to go through a website project and disable autocomplete on all password fields after a security scan as part of a PCI compliance process. For autofill password it didn’t seem to have any effect in _any_ browser I tested in. How can it be used to thwart password managers?
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.
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).
Decisions like this demonstrate an utter disregard for the crucial role Chromium plays in the web standardization process, and jeopardizes the entire ecosystem.
W.r.t. this particular decision, I feel a more reasonable approach here might have been to allow users to manually trigger autocomplete on individual fields with `autocomplete="off"`, and/or to allow users to strip away the ability to disable autocomplete on a site by site basis.
Analogously to how users are able to selectively grant access to certain default-off features for each website (notifications, camera access), users should also be able to revoke access to certain default-on features for sites that abuse them without affecting the vast majority of sites that use the features for their intended purposes to create a better user experience.
This isn't even the first time we've seen this either. Both Chrome Mobile and Safari Mobile go against the standard and implement `vh` incorrectly.
Honestly it seems strange that they go against the standard though considering how much power they have in defining it. Why break from the standard when you can just update the standard. It ends up being the worst of both worlds - documentation that says one thing (that they had a hand in building) and an implementation that does something completely different.
I ran into this last week (with LastPass, not Chrome - this seems to be a common practice):
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 overwrite the initial value. Even with autocomplete=off.
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 followed the spec I was relying on. 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.
Similar thing at my last job. Some internal webapp that was communicating with a bunch of other services. Whenever you edited the connection to such a backend you'd get a bunch of settings to change, as well as - depending on the backend type - credentials to talk to that other service. So if you were saving your credentials to that web app, whenever you edited such a backend connection, it would overwrite the username and password field in that settings page with your credentials for the web app itself. Even though the fields were pre-filled with the current values in the html the server sent you, chrome just went ahead and replaced them on page load. It happened more than once someone accidentally saved the settings and replaced the actual credentials for the backend with their login credentials for the webapp. So anyone accessing that edit page afterwards could steal their coworkers password.
So at some point a colleague went ahead, found the template and added a fake username and password field at the very beginning of the form that had something like "position: absolute; top: -2000" (after an hour of failed attempts with the autofill attribute and using hidden fields and whatnot).
So yes, f*ck those Google devs on their high horse.
The LastPass on is especially horrific because it fills in fields that are already filled, and it fires a change event. So if you're auto-saving on a change event, that data is lost as soon as the page is loaded.
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...
(And for the record: As a developer, I have been bitten by Chrome ignoring autocomplete="off" as well.)
This is a bit of a missing perspective. I wouldn't even care about them not following autocomplete=off if the damn autocomplete was useful. Instead 90% of the time I'm fighting it.
They really, really need to stop trying to autocomplete entire forms, and probably not anything other than "user/password" forms. The whole 'look at this input id and match it to a bunch of categories' approach has been thoroughly debunked as useless.
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.
Just like they already randomise asset filenames to avoid caching.
MDN literally mentions jquery.disableAutoFill which basically does that for you under the cover (scrambling the name on display, and unscrambling on submission).
Your comment about randomizing filenames got me thinking. It would be great if we could add a cache key to the HTML element, that way we could cache everything forever with the same filenames and still invalidate things by just making the key being the SHA of the deploy. Too bad that's not a thing.
lol, years and years ago (like 2005) as an attempt at stopping XSS and CSRF attacks and bots I came up with a system that named all the inputs a salted MD5 of the intended name with the salt randomly generated then stored in the users server side session.
It’s still a reasonably effective solution for CSRF, though there are much simpler options, but today’s bots largely have cookie jars so you will likely need a CAPTCHA.
This is why form elements should never be hidden after loading. Display none should be the default in the HTML for non-relevant content, which should be enough for most autofillers. It also prevents flashing of content when autofillers try to populate it, causing the hiding to delay, which I recently saw in a production app.
Frameworks like React and Vue don’t even render the HTML into the DOM until conditions are met so the situation is improving.
That begs the question, at which point does autofill happen in an iframe? So I pay for an ad, and have a password, creditcard number, address etc. form in the background. Does the browser autofil, or does it autofill when the user starts to fill in a form in the foreground?
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.
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.
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.
You're not the only one. I remember spending a good two days on it this year for a page where the user puts in their credentials for external integrations.
Does anybody have a clue why it does not show up there? The Google team must have done something in order to circumvent what the Chrome team did. Horrible.
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...?
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...).
1. Our programming language has an attribute called "autocomplete" with two possible values: "on" and "off"
2. We will now (without consultation or announcement) simply start ignoring one of those values when you specify it. (and certainly not document the new behaviour!)
3. Here, I made you a convoluted (and undocumented!) workaround for getting the original behaviour of the attribute back.
I'm not sure which horse these FAANG kids who excel at programming challenges rode in on, but this attitude is RIFE in their product SDK's and API's.
> somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users
And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
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.
That is absolutely stuff that the user needs to be able to override. In fact, anything related to cutting and pasting is not something I think the browser should mess with.
Also: websites that generate a custom login name or password for me so I won't remember it, and then refuse to allow autofill or pasting. Fortunately dev tools are standard on the desktop these days.
(I would really, really like access to dev tools on mobile, though. It's simply necessary to get around some broken websites.)
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.
The maps team seems to have given up on trying to resolve that.
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.
... 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.
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 is a direct spec violation, and it is breaking all kinds of applications.
Look, I get that this capability is super useful on shopping sites, and I rely on it practically every day.
But, I also build enterprise applications, where Chrome simply would not ever understand or know what would be valid choice.
I do, though; I built it. Invoice Numbers / Pre-Validated Travel Dates & Locations / Pre-Validated Locations / Pre-Validated IssueID that are so esoteric, we have built custom autocomplete that provide additional relevant information / Pre-Validated Users where the number of valid "John Smith"s number in the 10s, and additional meta data must be provided to differentiate.
Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. The spec says this is autocomplete=off. Just do that.
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.
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.
Indeed. Chrome and Firefox both autocomplete my user name and password into GitHub's new user registration form, even though I already have an account. It's flaky and just asking to be abused.
It's really frustrating to have to work around this with hit or miss hidden inputs and such.
So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text.
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.
> 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.
You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"
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.
The only time I saw this being a rogue developer was a commit and run done by a guy on his last day.
It is easy to blame one person when actually is a systemic failure that needs to be addressed at the company level.
I agree - and in fact, I think accusing this guy of being rogue is an unnecessary direct attack on him/her.
They are just doing their job, and in this case, acting in what they believe is best way for users. Here on HN, it seems most disagree, but that is still no reason to accuse someone of being rogue.
Headline should be "Google Chrome actively ignores HTML5 standard"
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.
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 https://www.openrent.co.uk.
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.
At some point the alternative will be to implement a custom input control, which will just be awful in all kinds of ways, but it's just as awful to have Chrome think it knows best in some contexts.
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.
I was thinking the same, websites should just have a big popup somewhere saying that the website might not work on Google Chrome, because it is W3C compliant and Google Chrome doesn't implement W3C standards, whith links to download alternatives browsers.
> 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).
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.
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?
<input --chrome-type="name"/>
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.
Chrome should remove the password if there is any attempt to change that form object.
This flaw has been there for years, it's actually handy if I'm not sure what the password is.
If you can modify the type of the field, you can also read the field's value without changing the type (e.g. document.getElementById('password').value from the console). Even just using the address bar via javascript:{alert(document.getElementById('password').value);}
As Raymond Chen and others call it: "the airtight hatchway problem."[0] Meaning you're sitting in a context where you can steal the password in infinite ways and complaining about the easiest one. But ultimately fixing that one way still leaves infinite remaining ways.
You're in the superuser context for the webpage. If you can modify the password field's type you can literally do anything to that page.
Is this really an issue? Presumably anyone with access to the browser can acces saved passwords anyways; the censoring only prevents onlookers from reading it.
>>> - How to trigger the hiding? - right mouse button menu or (more likely) something in the drop down? where would we put that? ...
Mobiles notoriously don't have mouse buttons, so any UI relying on right-click will not be usable there.
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?
> 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
I can't believe that this suggested hack is coming from google.
>
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
If you look at the chrome sources you can find this flag:
const char kAutofillOffNoServerDataDescription[] =
"Disables Autofill for fields with autocomplete off that have no "
"crowd-sourced evidence that Autofill would be helpful.";
So, at least in a company, this should work to avoid autocomplete making corporate apps unusable.
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.
"
please note that it uses "should", not "must". these words have precise definition in specs, see RFC2119:
"
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.
"
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.
> It seems to reduce the potential for security leaks
Misguided views like this are exactly how. Turning off autocomplete doesn't improve any sort of security, since the site already needs to trust the browser.
It serves no purpose other than to frustrate the user, and might even reduce security if it prevents the user from easily making use of a password manager.
From previous discussions I remember payment and bank forms use autocomplete=off and chrome developers don't like it, they want card numbers to be pre-filled.
I think some people want to be able to override it because some sites try to block password managers from filling the password field. Since Chrome has a built in password manager, that is likely their motivation to ignore it.
There was a time when IE was the dominant browser, and happily did whatever they wanted to.
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.
Some comments were deferred for faster rendering.
romaaeterna|6 years ago
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).
dmethvin|6 years ago
1570949436970|6 years ago
In certain cases, a previously-entered zip code was interpreted as the number of cents to tip.
userbinator|6 years ago
I wonder how much the [1] hiding of scrollbars and [2] UIs with excessive amounts of whitespace, increasing the need to scroll also contributed to you making this error.
jbeales|6 years ago
mehrdadn|6 years ago
sedatk|6 years ago
carstenhag|6 years ago
https://i.imgur.com/BjYTgSn.png
They have tagged the field as autocomplete=off but Chrome just doesn't care.
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).
https://bugs.chromium.org/p/chromium/issues/detail?id=587466
obituary_latte|6 years ago
watwut|6 years ago
Literally that and nothing more.
atVelocet|6 years ago
Seems that Chromium based browsers aren't favorable any more: Tracking, Bugs, uBlock extension is flagged, Manifestv3, etc.
But Firefox has the same problem since it ships with Pocket and other sync stuff. I know that they really do care but they have problems of their own which really make me think which browser to use. The actual situation right now is very frustrating...
lqet|6 years ago
E: as soon as you submit a search on sbb.ch, the same problem occurs.
lone_haxx0r|6 years ago
Another example of this is chrome hiding "trivial" parts of the URL. i.e. any subdomain that coincides with "www" or "m".
takeda|6 years ago
jmkni|6 years ago
Not ideal, but worked!
sandstrom|6 years ago
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.
https://stackoverflow.com/questions/12374442/chrome-ignores-...
obituary_latte|6 years ago
scient|6 years ago
EugeneOZ|6 years ago
rc_mob|6 years ago
[deleted]
clairity|6 years ago
great dash use! i almost read that as a race of sad chickens (seriously) but the dash autocorrected me. bravo!
jchw|6 years ago
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.
(I do not work on Chrome or use Chrome at home, but as disclosure I do currently work at Google.)
gnud|6 years ago
They could still follow it for other fields.
0: https://chromium.googlesource.com/chromium/src/+/master/docs...
anoncake|6 years ago
You autocomplete=off a password field? That attribute won't have an effect on your site anymore.
You auto-play videos when the user doesn't expect it? What videos? The web doesn't support videos – as far as you are concerned.
Scroll hijacking? I hope you used progressive enhancement because you just lost your Javascript privileges.
doctorpangloss|6 years ago
cdubzzz|6 years ago
ss3000|6 years ago
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).
Decisions like this demonstrate an utter disregard for the crucial role Chromium plays in the web standardization process, and jeopardizes the entire ecosystem.
ss3000|6 years ago
Analogously to how users are able to selectively grant access to certain default-off features for each website (notifications, camera access), users should also be able to revoke access to certain default-on features for sites that abuse them without affecting the vast majority of sites that use the features for their intended purposes to create a better user experience.
jjcm|6 years ago
Honestly it seems strange that they go against the standard though considering how much power they have in defining it. Why break from the standard when you can just update the standard. It ends up being the worst of both worlds - documentation that says one thing (that they had a hand in building) and an implementation that does something completely different.
ko27|6 years ago
isostatic|6 years ago
[deleted]
azernik|6 years ago
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 overwrite the initial value. Even with autocomplete=off.
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 followed the spec I was relying on. 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.
iforgotpassword|6 years ago
So at some point a colleague went ahead, found the template and added a fake username and password field at the very beginning of the form that had something like "position: absolute; top: -2000" (after an hour of failed attempts with the autofill attribute and using hidden fields and whatnot).
So yes, f*ck those Google devs on their high horse.
notatoad|6 years ago
Geeflow|6 years ago
(And for the record: As a developer, I have been bitten by Chrome ignoring autocomplete="off" as well.)
megous|6 years ago
TAB -> Arrow Down (select one of the previously filled values I've used) -> Enter
When filling a form. Given that sometimes we order things on made up names, it's quite useful no to have that autofilled when we're not wanting to.
stefan_|6 years ago
They really, really need to stop trying to autocomplete entire forms, and probably not anything other than "user/password" forms. The whole 'look at this input id and match it to a bunch of categories' approach has been thoroughly debunked as useless.
TekMol|6 years ago
Just like they already randomise asset filenames to avoid caching.
wiredfool|6 years ago
masklinn|6 years ago
StavrosK|6 years ago
ProfSarkov|6 years ago
donatj|6 years ago
It’s still a reasonably effective solution for CSRF, though there are much simpler options, but today’s bots largely have cookie jars so you will likely need a CAPTCHA.
xg15|6 years ago
But why? Isn't the whole point of caching to improve delivery if static assets?
Did they run into staleness problems? Then why not use if-modified-since/if-none-match?
mxxx|6 years ago
VMG|6 years ago
dmix|6 years ago
Frameworks like React and Vue don’t even render the HTML into the DOM until conditions are met so the situation is improving.
Another positive step away from jQuery hackery!
yk|6 years ago
Asking for a friend.
throwaway_bad|6 years ago
TazeTSchnitzel|6 years ago
Hamuko|6 years ago
sky_rw|6 years ago
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.
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.
sundbry|6 years ago
albertzeyer|6 years ago
<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="...">
carstenhag|6 years ago
goatinaboat|6 years ago
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?
ProfSarkov|6 years ago
People might not like the spec or it might be incomplete, but adhering to it is a very important part of improving it until it's a good one.
Now I'm no webdev, but I could very well imagine that the spec is already a good one. So the situation might be even worse.
shpx|6 years ago
lstamour|6 years ago
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...).
the_pwner224|6 years ago
https://bugs.chromium.org/p/chromium/issues/detail?id=468153...
antoinevg|6 years ago
1. Our programming language has an attribute called "autocomplete" with two possible values: "on" and "off"
2. We will now (without consultation or announcement) simply start ignoring one of those values when you specify it. (and certainly not document the new behaviour!)
3. Here, I made you a convoluted (and undocumented!) workaround for getting the original behaviour of the attribute back.
I'm not sure which horse these FAANG kids who excel at programming challenges rode in on, but this attitude is RIFE in their product SDK's and API's.
Dijkstra must be spinning in his grave.
Carpetsmoker|6 years ago
And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
GrayShade|6 years ago
mcv|6 years ago
Also: websites that generate a custom login name or password for me so I won't remember it, and then refuse to allow autofill or pasting. Fortunately dev tools are standard on the desktop these days.
(I would really, really like access to dev tools on mobile, though. It's simply necessary to get around some broken websites.)
elcritch|6 years ago
andrewstuart|6 years ago
The maps team seems to have given up on trying to resolve that.
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.
It's weird.
nikanj|6 years ago
jefftk|6 years ago
Isn't that how things should work? If other teams within Google had a special way to override autocomplete wouldn't that be worse?
(Disclosure: I work at Google)
xg15|6 years ago
by battre@google.com
... 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.
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.
bullman|6 years ago
Look, I get that this capability is super useful on shopping sites, and I rely on it practically every day.
But, I also build enterprise applications, where Chrome simply would not ever understand or know what would be valid choice.
I do, though; I built it. Invoice Numbers / Pre-Validated Travel Dates & Locations / Pre-Validated Locations / Pre-Validated IssueID that are so esoteric, we have built custom autocomplete that provide additional relevant information / Pre-Validated Users where the number of valid "John Smith"s number in the 10s, and additional meta data must be provided to differentiate.
Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. The spec says this is autocomplete=off. Just do that.
tannhaeuser|6 years ago
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.
Santosh83|6 years ago
duxup|6 years ago
So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text.
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.
johneth|6 years ago
You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"
Hokusai|6 years ago
The only time I saw this being a rogue developer was a commit and run done by a guy on his last day.
It is easy to blame one person when actually is a systemic failure that needs to be addressed at the company level.
londons_explore|6 years ago
They are just doing their job, and in this case, acting in what they believe is best way for users. Here on HN, it seems most disagree, but that is still no reason to accuse someone of being rogue.
Headline should be "Google Chrome actively ignores HTML5 standard"
speedplane|6 years ago
PerfectElement|6 years ago
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.
dazbradbury|6 years ago
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.
vidarh|6 years ago
andrewstuart|6 years ago
You cannot switch off Chrome's handling of autocomplete, thus any other autocomplete implementation will be overwritten by Chrome's handling.
Chrome team feel they know best.
chris_wot|6 years ago
oscargrouch|6 years ago
[deleted]
avodonosov|6 years ago
mgoetzke|6 years ago
needle0|6 years ago
avellable|6 years ago
dustinmoris|6 years ago
dang|6 years ago
"Rogue Chromium dev lead ignores W3C 'autocomplete' spec; frustrates Internet"
lowercased|6 years ago
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.
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?
<input --chrome-type="name"/>
This might make more sense, no? Let chrome try to determine a 'name' based on whatever logic they want.
velox_io|6 years ago
Chrome should remove the password if there is any attempt to change that form object.
This flaw has been there for years, it's actually handy if I'm not sure what the password is.
Someone1234|6 years ago
As Raymond Chen and others call it: "the airtight hatchway problem."[0] Meaning you're sitting in a context where you can steal the password in infinite ways and complaining about the easiest one. But ultimately fixing that one way still leaves infinite remaining ways.
You're in the superuser context for the webpage. If you can modify the password field's type you can literally do anything to that page.
[0] https://stackoverflow.com/questions/2787853/arent-passwords-...
Smithalicious|6 years ago
user5994461|6 years ago
Mobiles notoriously don't have mouse buttons, so any UI relying on right-click will not be usable there.
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?
packetized|6 years ago
https://github.com/whatwg/html/issues/4986
codegladiator|6 years ago
I can't believe that this suggested hack is coming from google.
https://bugs.chromium.org/p/chromium/issues/detail?id=914451...
platz|6 years ago
https://bugs.chromium.org/p/chromium/issues/detail?id=914451...
We're in for the Long haul on this one.
tyingq|6 years ago
https://news.ycombinator.com/item?id=13329525
marcoseliziario|6 years ago
const char kAutofillOffNoServerDataDescription[] = "Disables Autofill for fields with autocomplete off that have no " "crowd-sourced evidence that Autofill would be helpful.";
So, at least in a company, this should work to avoid autocomplete making corporate apps unusable.
another thing that seems to work for me, is adding role="combobox" along with autocomplete="off"
tehabe|6 years ago
asdf-asdf-asdf|6 years ago
please note that it uses "should", not "must". these words have precise definition in specs, see RFC2119:
" 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. "
one may argue whether chrome has valid reasons or not, but saying they ignore it is incorrect.
mstade|6 years ago
(Emphasis mine.)
Is it really spec compliant when the "particular" circumstance is all of them?
chris_wot|6 years ago
chris_wot|6 years ago
https://bugs.chromium.org/p/chromium/issues/detail?id=587466
marcoseliziario|6 years ago
role="combobox" autocomplete="off"
onion2k|6 years ago
aiCeivi9|6 years ago
dannykwells|6 years ago
sm4rk0|6 years ago
edoceo|6 years ago
Both Twilio and NameCheap seem to have login that defeat autocomplete in a nice way. Haven't investigate their tricks
mfer|6 years ago
Not the kind of relationship you want to build with an army of advocates
enriquto|6 years ago
robotstate|6 years ago
unknown|6 years ago
[deleted]
phendrenad2|6 years ago
smashah|6 years ago
wolco|6 years ago
iandanforth|6 years ago
tus88|6 years ago
pilif|6 years ago
Unfortunately, disabling autocomplete for password fields is an often used form of security-theatre
flaviu1|6 years ago
Misguided views like this are exactly how. Turning off autocomplete doesn't improve any sort of security, since the site already needs to trust the browser.
It serves no purpose other than to frustrate the user, and might even reduce security if it prevents the user from easily making use of a password manager.
avodonosov|6 years ago
bonestamp2|6 years ago
imode|6 years ago
Are we seriously expected to entertain this mess?
So glad I switched to Firefox all those years ago.
dustinmoris|6 years ago
vntok|6 years ago
bullman|6 years ago
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
sebazzz|6 years ago
IshKebab|6 years ago
rashad1234|6 years ago
[deleted]
platypii|6 years ago