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).
In certain cases, a previously-entered zip code was interpreted as the number of cents to tip.
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.
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
Literally that and nothing more.
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...
(The only thing that got me the first few weeks is that opening an incognito window is ctrl+shift+p instead of ctrl+shift+n. Once I got used to that I realized it actually makes sense because ctrl+shift+n re-opens a closed window just like ctrl+shift+t reopens a closed tab.)
E: as soon as you submit a search on sbb.ch, the same problem occurs.
https://i.imgur.com/NlzVqhT.png
and here's what it looks like when I enter 's':
https://i.imgur.com/1u4Iy7S.png
(actually, S does not autocomplete in the Swiss site)
Another example of this is chrome hiding "trivial" parts of the URL. i.e. any subdomain that coincides with "www" or "m".
Not ideal, but worked!
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-...
## 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">Sigh!
Naturally the problem is choice. Chrome/G should show a button to auto fill fields.
They could simply unleash some AI magic, train a network to recognize good and bad sites, etc. (Aka. the Apple way. As they also have a we know better policy, and users seem to love that.)
I wouldn't recommend it for public use. There's a lot of subtle behaviour around an input field that you'd need to replicate manually.
great dash use! i almost read that as a race of sad chickens (seriously) but the dash autocorrected me. bravo!
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.)
They could still follow it for other fields.
0: https://chromium.googlesource.com/chromium/src/+/master/docs...
Google should spend their cycles to work on a standard for password managers. The current design of those is flawed anyway.
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.
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.
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.
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.
Nevertheless, from their stance on the issue so far it stands to reason that the Chromium team would have objected to any efforts to tighten the spec, which would also have led us to this same situation.
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.
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.
(And for the record: As a developer, I have been bitten by Chrome ignoring autocomplete="off" as well.)
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.
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.
<input name="email">
<input name="16fkr9547kancot944128sddfksdf934998aafccugt75">
Just like they already randomise asset filenames to avoid caching.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
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.
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?
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!
Search boxes? Sure! App titles? Yeah, one week a bunch of our users' apps got renamed to the author's email address.
Being an IDE, of course, there are lots of places where inserting random text will break things. When I open up the console and see it filled with "'meredydd@anvil.works' is not a valid Python identifier"? That's the signal to go hunting for which dynamically-generated off-screen text box Chrome is stuffing credentials into this week.
TL;DR Chrome's autofill is out there. It can't be bargained with. It can't be reasoned with. It does not feel pity or remorse. And it will not stop.
Asking for a friend.
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.
<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="...">
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?
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.
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...).
https://bugs.chromium.org/p/chromium/issues/detail?id=468153...
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.
The research behind the number (25%) is highly dubious, because the video cited as the source doesn't tell how it was done. At all. Ironically, it follows a section on how MDN is documenting the standards, and how that "contribute(s) a lot".
[1] https://html.spec.whatwg.org/multipage/form-control-infrastr...
And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
Some daily annoyances that I wish browsers would actively mitigate, in no particular order: js-based redirects, blocking copy-paste, disabling text selection, hijacking the forward slash to open the website's own search function (I'm looking at you, Github), hijacking any of my other keyboard shortcuts that I rely on, creatively breaking my back and forward buttons (yes I realize there are legitimate reasons for some webapps), and overriding the built in right-click context menu.
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 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.
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)
This emphasises the craziness of the unilateral decision by the Chrome team which is essentially saying: "we, the Chrome team are correct and everyone else can go jump in the lake".
I'm not suggesting that Google should have secret special ways to do things.
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.
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.
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.
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.
You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"
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.
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"
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.
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.
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.
"Rogue Chromium dev lead ignores W3C 'autocomplete' spec; frustrates Internet"
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.
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.
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-...
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?
I can't believe that this suggested hack is coming from google.
https://bugs.chromium.org/p/chromium/issues/detail?id=914451...
https://bugs.chromium.org/p/chromium/issues/detail?id=914451...
We're in for the Long haul on this one.
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"
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.
(Emphasis mine.)
Is it really spec compliant when the "particular" circumstance is all of them?
https://bugs.chromium.org/p/chromium/issues/detail?id=587466
role="combobox" autocomplete="off"
Both Twilio and NameCheap seem to have login that defeat autocomplete in a nice way. Haven't investigate their tricks
Not the kind of relationship you want to build with an army of advocates
Unfortunately, disabling autocomplete for password fields is an often used form of security-theatre
Fortunately, Firefox gives me dom.event.clipboardevents.enabled so I at least need not worry about my workaround being broken.
As I said don't know what the answer is. I definitely want someone using password manager be able to use them. Using a password manager is a conscious choice with setups involved. Browser's default autocomplete is often not. I don't know how to separate these two out.
Sure, stupid devs can still work around that too, but so can they work around the current ingore-always behavior.
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.
Imagine if instead of autocomplete it was something like ignoring font sizes/color because they detected that engagement was low when font size was whatever so they render it differently. A browser should render HTML not make decisions like these
This happens when the auto-complete triggers on things it shouldn't and the user doesn't notice and submits personal details they never wanted to send to the site at all.
I've had to struggle a lot with working around Google's wrong-headed approach to this because this actually happens to real users. It's downright irresponsible, and I think frankly it's just a question of time before EU data protection watchdogs starts to take notice. All it will take is a sufficiently bad case of unintended disclosure of personal information (e.g. imagine a domestic abuse victim accidentally having their new address auto-completed in just the wrong situation).
(EDIT: this also easily happens with web apps where someone has to enter details for different users in the same forms multiple times; it get's very easy to end up not noticing Chrome auto-completing details for unrelated users; if that information is later visible to the user, it creates a real risk of leaking personal information)
When chrome devs believe it is their role to alter ux, they are backseat driving.
Already caught chrome doing this to my Social Security Number before i disabled the functionality entirely. The idea of Chrome automatically auto filling any form it sees labeled "SSN" on any site dosen't inspire confidence.
Are we seriously expected to entertain this mess?
So glad I switched to Firefox all those 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