12 ms·

Issue 914451: Autofill does not respect autocomplete="off"

820 points by bullman 7y ago

bullman 7y ago
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
- sebazzz 7y ago
  The most horrible is that it is almost completely unstylable, last time I checked. If you have floating placeholders it gets fun.
- IshKebab 7y ago
  They acted predictably by never updating IE and letting it stagnate. Hard to see how that is better in any meaningful way.
  - pjmlp 7y ago
    You still had a choice, nowadays being a Web Developer is almost a synonym for Chrome Developer and it was the IE hatting crowd that made it happen.
    - IshKebab 7y ago
      You didn't have a choice. That was the whole problem!
      - pjmlp 7y ago
        Well, shortly you won't have a choice anymore. And there was a choice, back then alternatives like Opera, did actually ship their own engine.
        IshKebab 7y ago
        We're not talking about choice for users. This is about choice for developers.
        pjmlp 7y ago
        Likewise I had Netscape, Opera, IE on my development environment.
        IshKebab 7y ago
        Are you being deliberately obtuse? Choice of which browsers to develop for. You had to support IE6 back in the day. Now you have to support Chrome. When they do weird shit you can't say "well that browser is broken", you have to work around it. Surely most people here are old enough to remember the days of IE6? It wasn't that long ago.
    - yoz-y 7y ago
      Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.
      - pjmlp 7y ago
        Mobile Safari is only relevant on first tier countries. Plenty of web sites aren't for international consumption.
      - capableweb 7y ago
        "the most "valuable" users are all on mobile Safari" Not at all, as only 20% of the people using mobile browsers at all, are using Safari.
        The_rationalist 7y ago
        To be accurate: Safari has 20% of mobile browser marketshare. And 5% of desktop browser marketshare. So globally they are <20%
        yoz-y 7y ago
        Yes but these users account for a very disproportionate amount of spending.
      - avodonosov 7y ago
        Doesn't matter, chrome started to ignore standards and dictate their understanding.
    - IfOnlyYouKnew 7y ago
      You must have lived in a different past than me. IE was far more dominant, and browsers actually had meaningful differences back then. Porting CSS written for IE to Firefox could easily take 50% of the initial implementation time, if not 100%. Today, it's not completely uncommon to have something developed on Chrome working in Firefox and Safari without any changes. And the most significant problem with IE was obviously that it wasn't FOSS, and was only available for Windows. Neither applies to Chrome.
      - pjmlp 7y ago
        Yeah all those Web sites that are Chrome only must be a product of my imagination. It doesn't matter if Chrome is open-source, when it is technically owned by a single corporation.
        The_rationalist 7y ago
        Update your beliefs.. Microsoft is now a major contributor to chromium.
        rndgermandude 7y ago
        [citation needed] They are now a major user of chromium, and may contribute, but they do not have any say in what goes into chromium. That is still controlled by google employees. If said google employees do not like microsoft patches, they will reject the proposed changes, and microsoft can then at best push them into their own fork.
        The_rationalist 7y ago
        Google rejecting Microsoft changes has not yet been observed, it could happen. Most people think that Google agenda could conflict with Microsoft agendas. I have read a LOT of chromium issues. I can tell you that the higher management at Google does not dictate chromium changes as they are too technical for them. The truth is, except for maybe a few exceptions, chromium evolve through the decisions of engineers that want to create the best possible product. They are not different to Firefox or edge engineers. Thus they should collaborate pretty well and a Google and Microsoft team should not have more "conflicts" than between two Google internal teams. As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox) You can see a list of their merged pull requests here: https://chromium-review.googlesource.com/q/author:*.microsoft.com+AND+status:merged https://chromium-review.googlesource.com/q/author:*.microsof... BTW I really wonder when Apple will switch back to chromium.
    - Gibbon1 7y ago
      I seriously can't wrap my head around why anyone decided it would somehow be 'okay' to use googles web browser. Because unless you are a Pollyanna coolaid drinker you know where that's going to lead us.
tus88 7y ago
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.
- flaviu1 7y ago
  > 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.
  - throwaway2048 7y ago
    plenty of stuff (like credit card info for instance) should absolutely never be auto-completed. The browser storing that sorta stuff to disk is stupid and completely avoidable. 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.
    - xmodem 7y ago
      One CRM webapp I worked on took our frontenders several attempts at different hacks to get Chrome to stop treating the SSN-equiv field as a credit card autofill.
      - DCoder 7y ago
        What are the odds that those hacks have been broken by Chrome updates since then?
        xmodem 7y ago
        Probably pretty high. I'm not on that team anymore, but the end users would have complained if it had happened.
the_pwner224 7y ago
Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c19 https://bugs.chromium.org/p/chromium/issues/detail?id=914451... https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164 https://bugs.chromium.org/p/chromium/issues/detail?id=468153...
- antoinevg 7y ago
  ...which really makes it worse: 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.
  - mehrdadn 7y ago
    I'm reminded of an earlier comment: https://news.ycombinator.com/item?id=21083277 https://news.ycombinator.com/item?id=21083277
  - tgv 7y ago
    All that based on an increase in page submissions. Is that the goal of auto-complete? 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".
  - mnoorenberghe 7y ago
    There are more than 20 different valid field name tokens in the spec, not just “on” and “off”[1]. If web developers actually used the other values correctly then user agents wouldn’t need to use heuristics to figure out the correct data to autofill. [1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#inappropriate-for-the-control https://html.spec.whatwg.org/multipage/form-control-infrastr...
duxup 7y ago
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.
- johneth 7y ago
  > 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"
  - duxup 7y ago
    I've found that auto complete still sometimes guesses at what to do in that case depending on what the other fields are. At least it did last time I fought with it.
enriquto 7y ago
I love the edited title of this post. It reflects accurately the reality of the situation. Hey, battre, hi there! You are famous now!
romaaeterna 7y ago
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).
- 1570949436970 7y ago
  Fun fact: something similar once happened in production in the early days of an iPad-based point of sale startup. In certain cases, a previously-entered zip code was interpreted as the number of cents to tip.
- mehrdadn 7y ago
  (How) did you resolve this?
  - lugg 7y ago
    Switched to Firefox.
    - mehrdadn 7y ago
      They give you back $1000 if you do that?
      - TylerE 7y ago
        Chargeback.
        mehrdadn 7y ago
        Is that allowed given that you appear to have authorized it and they have proof (it's obviously not fraud or something like that)?
lstamour 7y ago
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...).
dannykwells 7y ago
A rare example where an editorialized HN post title is appreciated. Bravo!
sky_rw 7y ago
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.
- sundbry 7y ago
  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.
tehabe 7y ago
I guess this bug is the real reason why I turned off auto-fill in the browser a while ago, because it acted weird a lot of times.
azernik 7y ago
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.
- iforgotpassword 7y ago
  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.
- notatoad 7y ago
  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.
avodonosov 7y ago
Bad that chrome developers don't practice web development enough to know the use cases where ignoring autocomplete=off breaks the application.
onion2k 7y ago
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.
tannhaeuser 7y ago
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.
- Santosh83 7y ago
  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.
jchw 7y ago
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.)
- doctorpangloss 7y ago
  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.
  - Nitramp 7y ago
    I have my own extension for Chrome that yanks the autocomplete attribute. I much rather deal with over eager completion than websites disabling it for silly reasons and pseudo security.
  - httpsterio 7y ago
    Touch based are not better. Your fingerprint is not a password, it's just an identifier and shouldn't be treated as a secret.
    - dustinmoris 7y ago
      > Your fingerprint is not a password Correct, because a fingerprint makes a password to some extent redundant. > it's just an identifier and shouldn't be treated as a secret Correct, identifiers are not secrets. Your face is not a secret and your fingerprint either. The problem is that we use secrets to identfy someone, when we potentially already have tech which can identify someone without having to remember a secret and store it in a dictionary of secrets on someone else's computer in the cloud. The sole purpose of a password is to identify someone with a certain degree of confidence. If a fingerprint taken from a handheld device, which has already been proven to belong to a person, can provide the same if not even a higher level of certainty about someone's identy, then a password or as you say "secret" is not required at all anymore.
goatinaboat 7y ago
Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off" 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?
- shpx 7y ago
  autocomplete=off is set by website developers, not users.
  - jussij 7y ago
    However the more important point made by the OP still remains which was some random Google employee chooses to ignore it.
- ProfSarkov 7y ago
  It's also in the spec. 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.
  - nikanj 7y ago
    The spec only says "should", not "must". Apparently these wingnuts thought that means the spec can be ignored.
    - reificator 7y ago
      > The spec only says "should", not "must". Apparently these wingnuts thought that means the spec can be ignored. Not arguing in favor of this particular choice, but yes. That is exactly what "should" means in most cases. For instance, in RFC 2119: https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/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.
Hokusai 7y ago
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.
- londons_explore 7y ago
  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"
  - jefftk 7y ago
    The standard says "SHOULD", not "MUST". (Disclosure: I work for Google)
    - craftinator 7y ago
      And not following the spec recommendation has gotten us... Here. Where Google is protecting users from both bad actors and good actors, whether the user likes it or not! The overwhelming response to this issue makes it clear that the heuristics used are simply not good ENOUGH. They can't accurately predict the best user outcome in a majority of situations. The Chrome team has wrenched the onus of autofill responsibility from all other developers, then fumbled it, badly. A good fix for this is to give the onus to the user. Popup toggle buttons, labeled: Autofill: Yes, No, Auto. This means we can all stop hating Chrome team for being patronizing, stop hating web devs for being unable to make their beautiful apps work in our godawful browsers, and start hating ourselves instead!
    - azernik 7y ago
TekMol 7y ago
I guess this will lead to a horrible coding style where instead of having this in the form: <input name="email"> We will see stuff like this: <input name="16fkr9547kancot944128sddfksdf934998aafccugt75"> 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.
- wiredfool 7y ago
  I’m doing this with a field where I provide server side autocomplete of an item. It sucks, but I can’t find a better workaround.
- donatj 7y ago
  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.
  - Thorrez 7y ago
    How would it stop XSS? Is it meant to stop attackers from getting JS execution on your site, or to mitigate the attackers' abilities after they have JS execution? I don't see how it would do either.
    - justicz 7y ago
      Maybe they mean CSRF? Then things make more sense since you can’t guess the field names cross-origin.
    - donatj 7y ago
      I mean both CSRF and XSS. If your inputs are named something different on everyone’s machine, per session, you can only XSS yourself. Not very useful, you can already do in many other ways. Also my comment above is not an endorsement of the methodology, it’s just a thing that happened.
carstenhag 7y ago
As I had already commented on the issue, it completely breaks Germany's main train ticket selling website: https://i.imgur.com/BjYTgSn.png 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 https://bugs.chromium.org/p/chromium/issues/detail?id=587466
- watwut 7y ago
  Imo, valid use case for autocomplete=off is "the developer of webapp wants it". Literally that and nothing more.
  - Nitramp 7y ago
    It's called "user agent", not "developer's agent". We'd be in a terrible situation if the browsers just followed developer's whims. Cf. popup blocking.
    - sky_rw 7y ago
      Dismissing the above use cases as "developer's whims" is the fundamental issue most people here are taking with these decisions. I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. We are arguing for following a guideline that makes sense. This is why we have the w3c, an organization that attempts to weigh the needs of user, developers, and browser maintainers.
      - deleted 7y ago
        [deleted]
      - TeMPOraL 7y ago
        The issue is that the browser is supposed to be the meeting place for negotiating between developer and user preferences. Its job is to take into account preferences of both sides, and render the site accordingly. Not to be a third party at the negotiating table. Breaking agreed standard in a way that can't be overridden by the user? Browsers should never do that.
VMG 7y ago
Autofill for offscreen elements gives me the creeps even without the data getting misinterpreted
- dmix 7y ago
  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. Another positive step away from jQuery hackery!
  - pantalaimon 7y ago
    If you want to be malicious and capture wrong auto fill data, wouldn't a simple AJAX request on change be enough to capture sensitive data before the user gets a chance to correct it?
    - AJ007 7y ago
      Yes, and there are popular third party analytics platforms that record all activity on a page, which includes not just every key press, but the speed at which it was done, with or without a submission of the form. Web browsers should never, ever use auto fill unless the user has already entered that information on that domain already. Popular domains that host third party content should never be able to auto fill.
    - HeavyStorm 7y ago
      I'm not really sure but I think the behavior is a bit different with autofill. While the browser show the field highlighted, the data is there for _the user_ but the actual form field has not been actually changed and no dom event is fired.
  - meredydd 7y ago
    If you think late rendering or "display:none" will put Chrome off, think again! The anvil.works IDE is Angular, so it's all rendered post-loading, and Chrome still autofills the weirdest things. Relentlessly. 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.
speedplane 7y ago
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.
andrewstuart 7y ago
The Chrome dev team have implemented autocomplete the way they think it should work, not the way web developers want. 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.
- oscargrouch 7y ago
  When i see something like this, i also remember that Google is basically a private "spy" company, that benefits the most by having all the data they can of each one of us. So my feeling is theres must be a lot of pressure inside Google management to not let such a feature be turned of, giving this get sent to the 'mothership' as you type, with the lag you take, fingerprinting etc.. Its a big problem that a company that does what Google do, owns the most popular browser client and the most popular mobile OS where they can serve the interests of the mother company against our own self interest where we want our privacy and major political and civil freedoms respected in the process.
- chris_wot 7y ago
  They are becoming the Gnome of browsers. The Chrome dev team seem to be getting more and more user hostile.
  - nordsieck 7y ago
    > They are becoming the Gnome of browsers. What they're becoming is ie6.
GrayShade 7y ago
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.
- elcritch 7y ago
  In best cases there’d be an option to honor the attribute or not.
- mcv 7y ago
  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.)
imode 7y ago
Is "ignoring the specification" an extreme, now? Are we seriously expected to entertain this mess? So glad I switched to Firefox all those years ago.
- dustinmoris 7y ago
  Google slaves came to downvote you after someone said this on their internal chat lol.
- vntok 7y ago
  The spec says SHOULD though, not MUST. Chrome is compliant.
chris_wot 7y ago
Previously closed as WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=468153 https://bugs.chromium.org/p/chromium/issues/detail?id=468153
- chris_wot 7y ago
  Later they filed: https://bugs.chromium.org/p/chromium/issues/detail?id=587466 https://bugs.chromium.org/p/chromium/issues/detail?id=587466
packetized 7y ago
This position seems at odds with a recently opened WHATWG issue. https://github.com/whatwg/html/issues/4986 https://github.com/whatwg/html/issues/4986
Geeflow 7y ago
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.)
- megous 7y ago
  Yup, I like how FF does it. I basically just do a repeated sequence of: 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_ 7y ago
  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.
ss3000 7y ago
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.
- isostatic 7y ago
  It’s heresy on HN to suggest that a single browser running the web is a bad idea.
  - wyattpeak 7y ago
    HN comments pretty consistently argue that browser monoculture is a problem. I don't know where you're getting this.
  - mcv 7y ago
    I think you're stumbling over too many negations here. A single browser running the web is a bad idea. Diversity in browsers is a good idea. If any statement related to this could be heresy here, then it would be heresy to suggest that a single browser running the web is a good idea.
- ko27 7y ago
  Strictly speaking, Chrome is not ignoring a web standard, since the standard does not require this behavior (no "MUST" keyword).
  - 7y ago
andrewstuart 7y ago
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. It's weird.
- jefftk 7y ago
  > not even other teams within Google are allowed to override that functionality 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)
  - andrewstuart 7y ago
    My point is that this decision from the Chrome team even breaks Google's own software. 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.
    - atomicfiredoll 7y ago
      Angular Material's Autocomplete component is an example of this. Our users would have found that really helpful... if Chrome's autofill behavior didn't break it.
- nikanj 7y ago
  Google really is the new Microsoft
  - sixothree 7y ago
    In spirit maybe. But in practice it seems worse.
asdf-asdf-asdf 7y ago
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.
- mstade 7y ago
  > [...] there may exist valid reasons in particular circumstances [...] (Emphasis mine.) Is it really spec compliant when the "particular" circumstance is all of them?
dang 7y ago
The submitted title was heavily editorialized: "Rogue Chromium dev lead ignores W3C 'autocomplete' spec; frustrates Internet"
xg15 7y ago
Relevant reply from a Googler seems to be this: https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66 https://bugs.chromium.org/p/chromium/issues/detail?id=914451... 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 7y ago
  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.
needle0 7y ago
Another reason to abandon ship and switch to Firefox.
sandstrom 7y ago
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. https://stackoverflow.com/questions/12374442/chrome-ignores-autocomplete-off 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">
- obituary_latte 7y ago
  I think it mentioned chrome is even now ignoring ‘display:none’ and ‘visibility:hidden’ declarations so those workarounds no longer work either.
  - msclrhd 7y ago
    Great! :( Now I need to recheck to see if an autocomplete bug has reappeared where it thinks an email address field is a username field in a change password UI and autocompletes the email address with the username from the login page. Sigh!
    - obituary_latte 7y ago
      I feel your pain - sorry you have to deal with it. I’m working on a client data management app and I’m having issues everywhere with this. It’s been an open ticket on Jira for months!
codegladiator 7y ago
> 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. https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c63 https://bugs.chromium.org/p/chromium/issues/detail?id=914451...
dazbradbury 7y ago
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 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.
- vidarh 7y ago
  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.
edoceo 7y ago
I use autocomplete="x" and it seems to work for my apps. Both Twilio and NameCheap seem to have login that defeat autocomplete in a nice way. Haven't investigate their tricks
avellable 7y ago
With the new direction chrome is going I wouldn't mind putting "works best on anything but Chrome" on my next web project.
- dustinmoris 7y ago
  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.
  - vntok 7y ago
    Please go read the spec, you will find that Chrome is perfectly compliant with it regarding the autocomplete attribute handling.
platz 7y ago
> 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 https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66 https://bugs.chromium.org/p/chromium/issues/detail?id=914451... We're in for the Long haul on this one.
mfer 7y ago
> This has turned into a sad tit-for-tat between developers and Chrome, where no-one is winning. Not the kind of relationship you want to build with an army of advocates
rashad1234 7y ago
Ctfvjjc
sm4rk0 7y ago
Just stop using Chrome. There are good (even better) alternatives.
PerfectElement 7y ago
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.
user5994461 7y ago
>>> - 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?
lowercased 7y ago
> 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.
velox_io 7y ago
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.
- Smithalicious 7y ago
  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.
  - Avamander 7y ago
    Actually on Windows at least Chrome asks for a password when trying to view all passwords. So it isn't _that_ easy.
- Someone1234 7y ago
  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. [0] https://stackoverflow.com/questions/2787853/arent-passwords-written-in-inputbox-vulnerable-through-a-stack-trace https://stackoverflow.com/questions/2787853/arent-passwords-...
tyingq 7y ago
Discussion about a demo of the issue... https://news.ycombinator.com/item?id=13329525 https://news.ycombinator.com/item?id=13329525
deleted 7y ago
[deleted]
smashah 7y ago
This also screws with notion to the point where I've largely stopped using it at all
albertzeyer 7y ago
Btw, at http://google.com http://google.com, this is what they have for the search field: <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 7y ago
  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.
wolco 7y ago
As a developer this can be fixed by using unique field names.
phendrenad2 7y ago
I wonder what kind of engine overhaul Chrome is doing to cause all of these strange breakages.
platypii 7y ago
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.
robotstate 7y ago
I wrote a Medium article on how to actually turn it off 3 years ago that consistently gets about 500 views a week to this day.
mgoetzke 7y ago
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.
marcoseliziario 7y ago
So far this combinations seems to be working for me role="combobox" autocomplete="off"
marcoseliziario 7y ago
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"
aiCeivi9 7y ago
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.
iandanforth 7y ago
We're Google, we don't have to respect the spec.

820 points by bullman 7y ago

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

sebazzz 7y ago
The most horrible is that it is almost completely unstylable, last time I checked. If you have floating placeholders it gets fun.
IshKebab 7y ago
They acted predictably by never updating IE and letting it stagnate. Hard to see how that is better in any meaningful way.
- pjmlp 7y ago
  You still had a choice, nowadays being a Web Developer is almost a synonym for Chrome Developer and it was the IE hatting crowd that made it happen.
  - IshKebab 7y ago
    You didn't have a choice. That was the whole problem!
    - pjmlp 7y ago
      Well, shortly you won't have a choice anymore. And there was a choice, back then alternatives like Opera, did actually ship their own engine.
      - IshKebab 7y ago
        We're not talking about choice for users. This is about choice for developers.
        pjmlp 7y ago
        Likewise I had Netscape, Opera, IE on my development environment.
        IshKebab 7y ago
        Are you being deliberately obtuse? Choice of which browsers to develop for. You had to support IE6 back in the day. Now you have to support Chrome. When they do weird shit you can't say "well that browser is broken", you have to work around it. Surely most people here are old enough to remember the days of IE6? It wasn't that long ago.
  - yoz-y 7y ago
    Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.
    - pjmlp 7y ago
      Mobile Safari is only relevant on first tier countries. Plenty of web sites aren't for international consumption.
    - capableweb 7y ago
      "the most "valuable" users are all on mobile Safari" Not at all, as only 20% of the people using mobile browsers at all, are using Safari.
      - The_rationalist 7y ago
        To be accurate: Safari has 20% of mobile browser marketshare. And 5% of desktop browser marketshare. So globally they are <20%
      - yoz-y 7y ago
        Yes but these users account for a very disproportionate amount of spending.
    - avodonosov 7y ago
      Doesn't matter, chrome started to ignore standards and dictate their understanding.
  - IfOnlyYouKnew 7y ago
    You must have lived in a different past than me. IE was far more dominant, and browsers actually had meaningful differences back then. Porting CSS written for IE to Firefox could easily take 50% of the initial implementation time, if not 100%. Today, it's not completely uncommon to have something developed on Chrome working in Firefox and Safari without any changes. And the most significant problem with IE was obviously that it wasn't FOSS, and was only available for Windows. Neither applies to Chrome.
    - pjmlp 7y ago
      Yeah all those Web sites that are Chrome only must be a product of my imagination. It doesn't matter if Chrome is open-source, when it is technically owned by a single corporation.
      - The_rationalist 7y ago
        Update your beliefs.. Microsoft is now a major contributor to chromium.
        rndgermandude 7y ago
        [citation needed] They are now a major user of chromium, and may contribute, but they do not have any say in what goes into chromium. That is still controlled by google employees. If said google employees do not like microsoft patches, they will reject the proposed changes, and microsoft can then at best push them into their own fork.
        The_rationalist 7y ago
        Google rejecting Microsoft changes has not yet been observed, it could happen. Most people think that Google agenda could conflict with Microsoft agendas. I have read a LOT of chromium issues. I can tell you that the higher management at Google does not dictate chromium changes as they are too technical for them. The truth is, except for maybe a few exceptions, chromium evolve through the decisions of engineers that want to create the best possible product. They are not different to Firefox or edge engineers. Thus they should collaborate pretty well and a Google and Microsoft team should not have more "conflicts" than between two Google internal teams. As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox) You can see a list of their merged pull requests here: https://chromium-review.googlesource.com/q/author:*.microsoft.com+AND+status:merged https://chromium-review.googlesource.com/q/author:*.microsof... BTW I really wonder when Apple will switch back to chromium.
  - Gibbon1 7y ago
    I seriously can't wrap my head around why anyone decided it would somehow be 'okay' to use googles web browser. Because unless you are a Pollyanna coolaid drinker you know where that's going to lead us.

tus88 7y ago

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.

flaviu1 7y ago
> 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.
- throwaway2048 7y ago
  plenty of stuff (like credit card info for instance) should absolutely never be auto-completed. The browser storing that sorta stuff to disk is stupid and completely avoidable. 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.
  - xmodem 7y ago
    One CRM webapp I worked on took our frontenders several attempts at different hacks to get Chrome to stop treating the SSN-equiv field as a credit card autofill.
    - DCoder 7y ago
      What are the odds that those hacks have been broken by Chrome updates since then?
      - xmodem 7y ago
        Probably pretty high. I'm not on that team anymore, but the end users would have complained if it had happened.

the_pwner224 7y ago

Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c19 https://bugs.chromium.org/p/chromium/issues/detail?id=914451... https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164 https://bugs.chromium.org/p/chromium/issues/detail?id=468153...

antoinevg 7y ago
...which really makes it worse: 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.
- mehrdadn 7y ago
  I'm reminded of an earlier comment: https://news.ycombinator.com/item?id=21083277 https://news.ycombinator.com/item?id=21083277
- tgv 7y ago
  All that based on an increase in page submissions. Is that the goal of auto-complete? 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".
- mnoorenberghe 7y ago
  There are more than 20 different valid field name tokens in the spec, not just “on” and “off”[1]. If web developers actually used the other values correctly then user agents wouldn’t need to use heuristics to figure out the correct data to autofill. [1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#inappropriate-for-the-control https://html.spec.whatwg.org/multipage/form-control-infrastr...

duxup 7y ago

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.

johneth 7y ago
> 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"
- duxup 7y ago
  I've found that auto complete still sometimes guesses at what to do in that case depending on what the other fields are. At least it did last time I fought with it.

enriquto 7y ago

I love the edited title of this post. It reflects accurately the reality of the situation. Hey, battre, hi there! You are famous now!

romaaeterna 7y ago

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

1570949436970 7y ago
Fun fact: something similar once happened in production in the early days of an iPad-based point of sale startup. In certain cases, a previously-entered zip code was interpreted as the number of cents to tip.
mehrdadn 7y ago
(How) did you resolve this?
- lugg 7y ago
  Switched to Firefox.
  - mehrdadn 7y ago
    They give you back $1000 if you do that?
    - TylerE 7y ago
      Chargeback.
      - mehrdadn 7y ago
        Is that allowed given that you appear to have authorized it and they have proof (it's obviously not fraud or something like that)?

lstamour 7y ago

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

dannykwells 7y ago

A rare example where an editorialized HN post title is appreciated. Bravo!

sky_rw 7y ago

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.

sundbry 7y ago
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.

tehabe 7y ago

I guess this bug is the real reason why I turned off auto-fill in the browser a while ago, because it acted weird a lot of times.

azernik 7y ago

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.

iforgotpassword 7y ago
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.
notatoad 7y ago
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.

avodonosov 7y ago

Bad that chrome developers don't practice web development enough to know the use cases where ignoring autocomplete=off breaks the application.

onion2k 7y ago

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.

tannhaeuser 7y ago

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.

Santosh83 7y ago
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.

jchw 7y ago

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

doctorpangloss 7y ago
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.
- Nitramp 7y ago
  I have my own extension for Chrome that yanks the autocomplete attribute. I much rather deal with over eager completion than websites disabling it for silly reasons and pseudo security.
- httpsterio 7y ago
  Touch based are not better. Your fingerprint is not a password, it's just an identifier and shouldn't be treated as a secret.
  - dustinmoris 7y ago
    > Your fingerprint is not a password Correct, because a fingerprint makes a password to some extent redundant. > it's just an identifier and shouldn't be treated as a secret Correct, identifiers are not secrets. Your face is not a secret and your fingerprint either. The problem is that we use secrets to identfy someone, when we potentially already have tech which can identify someone without having to remember a secret and store it in a dictionary of secrets on someone else's computer in the cloud. The sole purpose of a password is to identify someone with a certain degree of confidence. If a fingerprint taken from a handheld device, which has already been proven to belong to a person, can provide the same if not even a higher level of certainty about someone's identy, then a password or as you say "secret" is not required at all anymore.

goatinaboat 7y ago

Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off" 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?

shpx 7y ago
autocomplete=off is set by website developers, not users.
- jussij 7y ago
  However the more important point made by the OP still remains which was some random Google employee chooses to ignore it.
ProfSarkov 7y ago
It's also in the spec. 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.
- nikanj 7y ago
  The spec only says "should", not "must". Apparently these wingnuts thought that means the spec can be ignored.
  - reificator 7y ago
    > The spec only says "should", not "must". Apparently these wingnuts thought that means the spec can be ignored. Not arguing in favor of this particular choice, but yes. That is exactly what "should" means in most cases. For instance, in RFC 2119: https://tools.ietf.org/html/rfc2119 https://tools.ietf.org/html/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.

Hokusai 7y ago

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.

londons_explore 7y ago
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"
- jefftk 7y ago
  The standard says "SHOULD", not "MUST". (Disclosure: I work for Google)
  - craftinator 7y ago
    And not following the spec recommendation has gotten us... Here. Where Google is protecting users from both bad actors and good actors, whether the user likes it or not! The overwhelming response to this issue makes it clear that the heuristics used are simply not good ENOUGH. They can't accurately predict the best user outcome in a majority of situations. The Chrome team has wrenched the onus of autofill responsibility from all other developers, then fumbled it, badly. A good fix for this is to give the onus to the user. Popup toggle buttons, labeled: Autofill: Yes, No, Auto. This means we can all stop hating Chrome team for being patronizing, stop hating web devs for being unable to make their beautiful apps work in our godawful browsers, and start hating ourselves instead!
  - azernik 7y ago

TekMol 7y ago

I guess this will lead to a horrible coding style where instead of having this in the form: <input name="email"> We will see stuff like this: <input name="16fkr9547kancot944128sddfksdf934998aafccugt75"> 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.

wiredfool 7y ago
I’m doing this with a field where I provide server side autocomplete of an item. It sucks, but I can’t find a better workaround.
donatj 7y ago
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.
- Thorrez 7y ago
  How would it stop XSS? Is it meant to stop attackers from getting JS execution on your site, or to mitigate the attackers' abilities after they have JS execution? I don't see how it would do either.
  - justicz 7y ago
    Maybe they mean CSRF? Then things make more sense since you can’t guess the field names cross-origin.
  - donatj 7y ago
    I mean both CSRF and XSS. If your inputs are named something different on everyone’s machine, per session, you can only XSS yourself. Not very useful, you can already do in many other ways. Also my comment above is not an endorsement of the methodology, it’s just a thing that happened.

carstenhag 7y ago

As I had already commented on the issue, it completely breaks Germany's main train ticket selling website: https://i.imgur.com/BjYTgSn.png 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 https://bugs.chromium.org/p/chromium/issues/detail?id=587466

watwut 7y ago
Imo, valid use case for autocomplete=off is "the developer of webapp wants it". Literally that and nothing more.
- Nitramp 7y ago
  It's called "user agent", not "developer's agent". We'd be in a terrible situation if the browsers just followed developer's whims. Cf. popup blocking.
  - sky_rw 7y ago
    Dismissing the above use cases as "developer's whims" is the fundamental issue most people here are taking with these decisions. I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. We are arguing for following a guideline that makes sense. This is why we have the w3c, an organization that attempts to weigh the needs of user, developers, and browser maintainers.
    - deleted 7y ago
      [deleted]
    - TeMPOraL 7y ago
      The issue is that the browser is supposed to be the meeting place for negotiating between developer and user preferences. Its job is to take into account preferences of both sides, and render the site accordingly. Not to be a third party at the negotiating table. Breaking agreed standard in a way that can't be overridden by the user? Browsers should never do that.

VMG 7y ago

Autofill for offscreen elements gives me the creeps even without the data getting misinterpreted

dmix 7y ago
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. Another positive step away from jQuery hackery!
- pantalaimon 7y ago
  If you want to be malicious and capture wrong auto fill data, wouldn't a simple AJAX request on change be enough to capture sensitive data before the user gets a chance to correct it?
  - AJ007 7y ago
    Yes, and there are popular third party analytics platforms that record all activity on a page, which includes not just every key press, but the speed at which it was done, with or without a submission of the form. Web browsers should never, ever use auto fill unless the user has already entered that information on that domain already. Popular domains that host third party content should never be able to auto fill.
  - HeavyStorm 7y ago
    I'm not really sure but I think the behavior is a bit different with autofill. While the browser show the field highlighted, the data is there for _the user_ but the actual form field has not been actually changed and no dom event is fired.
- meredydd 7y ago
  If you think late rendering or "display:none" will put Chrome off, think again! The anvil.works IDE is Angular, so it's all rendered post-loading, and Chrome still autofills the weirdest things. Relentlessly. 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.

speedplane 7y ago

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.

andrewstuart 7y ago

The Chrome dev team have implemented autocomplete the way they think it should work, not the way web developers want. 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.

oscargrouch 7y ago
When i see something like this, i also remember that Google is basically a private "spy" company, that benefits the most by having all the data they can of each one of us. So my feeling is theres must be a lot of pressure inside Google management to not let such a feature be turned of, giving this get sent to the 'mothership' as you type, with the lag you take, fingerprinting etc.. Its a big problem that a company that does what Google do, owns the most popular browser client and the most popular mobile OS where they can serve the interests of the mother company against our own self interest where we want our privacy and major political and civil freedoms respected in the process.
chris_wot 7y ago
They are becoming the Gnome of browsers. The Chrome dev team seem to be getting more and more user hostile.
- nordsieck 7y ago
  > They are becoming the Gnome of browsers. What they're becoming is ie6.

GrayShade 7y ago

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.

elcritch 7y ago
In best cases there’d be an option to honor the attribute or not.
mcv 7y ago
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.)

imode 7y ago

Is "ignoring the specification" an extreme, now? Are we seriously expected to entertain this mess? So glad I switched to Firefox all those years ago.

dustinmoris 7y ago
Google slaves came to downvote you after someone said this on their internal chat lol.
vntok 7y ago
The spec says SHOULD though, not MUST. Chrome is compliant.

chris_wot 7y ago

Previously closed as WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=468153 https://bugs.chromium.org/p/chromium/issues/detail?id=468153

chris_wot 7y ago
Later they filed: https://bugs.chromium.org/p/chromium/issues/detail?id=587466 https://bugs.chromium.org/p/chromium/issues/detail?id=587466

packetized 7y ago

This position seems at odds with a recently opened WHATWG issue. https://github.com/whatwg/html/issues/4986 https://github.com/whatwg/html/issues/4986

Geeflow 7y ago

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

megous 7y ago
Yup, I like how FF does it. I basically just do a repeated sequence of: 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_ 7y ago
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.

ss3000 7y ago

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.

isostatic 7y ago
It’s heresy on HN to suggest that a single browser running the web is a bad idea.
- wyattpeak 7y ago
  HN comments pretty consistently argue that browser monoculture is a problem. I don't know where you're getting this.
- mcv 7y ago
  I think you're stumbling over too many negations here. A single browser running the web is a bad idea. Diversity in browsers is a good idea. If any statement related to this could be heresy here, then it would be heresy to suggest that a single browser running the web is a good idea.
ko27 7y ago
Strictly speaking, Chrome is not ignoring a web standard, since the standard does not require this behavior (no "MUST" keyword).
- 7y ago

andrewstuart 7y ago

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. It's weird.

jefftk 7y ago
> not even other teams within Google are allowed to override that functionality 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)
- andrewstuart 7y ago
  My point is that this decision from the Chrome team even breaks Google's own software. 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.
  - atomicfiredoll 7y ago
    Angular Material's Autocomplete component is an example of this. Our users would have found that really helpful... if Chrome's autofill behavior didn't break it.
nikanj 7y ago
Google really is the new Microsoft
- sixothree 7y ago
  In spirit maybe. But in practice it seems worse.

asdf-asdf-asdf 7y ago

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.

mstade 7y ago
> [...] there may exist valid reasons in particular circumstances [...] (Emphasis mine.) Is it really spec compliant when the "particular" circumstance is all of them?

dang 7y ago

The submitted title was heavily editorialized: "Rogue Chromium dev lead ignores W3C 'autocomplete' spec; frustrates Internet"

xg15 7y ago

Relevant reply from a Googler seems to be this: https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66 https://bugs.chromium.org/p/chromium/issues/detail?id=914451... 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 7y ago
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.

needle0 7y ago

Another reason to abandon ship and switch to Firefox.

sandstrom 7y ago

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. https://stackoverflow.com/questions/12374442/chrome-ignores-autocomplete-off 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">

obituary_latte 7y ago
I think it mentioned chrome is even now ignoring ‘display:none’ and ‘visibility:hidden’ declarations so those workarounds no longer work either.
- msclrhd 7y ago
  Great! :( Now I need to recheck to see if an autocomplete bug has reappeared where it thinks an email address field is a username field in a change password UI and autocompletes the email address with the username from the login page. Sigh!
  - obituary_latte 7y ago
    I feel your pain - sorry you have to deal with it. I’m working on a client data management app and I’m having issues everywhere with this. It’s been an open ticket on Jira for months!

codegladiator 7y ago

> 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. https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c63 https://bugs.chromium.org/p/chromium/issues/detail?id=914451...

dazbradbury 7y ago

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

vidarh 7y ago
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.

edoceo 7y ago

I use autocomplete="x" and it seems to work for my apps. Both Twilio and NameCheap seem to have login that defeat autocomplete in a nice way. Haven't investigate their tricks

avellable 7y ago

With the new direction chrome is going I wouldn't mind putting "works best on anything but Chrome" on my next web project.

dustinmoris 7y ago
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.
- vntok 7y ago
  Please go read the spec, you will find that Chrome is perfectly compliant with it regarding the autocomplete attribute handling.

platz 7y ago

> 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 https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66 https://bugs.chromium.org/p/chromium/issues/detail?id=914451... We're in for the Long haul on this one.

mfer 7y ago

> This has turned into a sad tit-for-tat between developers and Chrome, where no-one is winning. Not the kind of relationship you want to build with an army of advocates

rashad1234 7y ago

Ctfvjjc

sm4rk0 7y ago

Just stop using Chrome. There are good (even better) alternatives.

PerfectElement 7y ago

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.

user5994461 7y ago

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

lowercased 7y ago

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

velox_io 7y ago

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.

Smithalicious 7y ago
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.
- Avamander 7y ago
  Actually on Windows at least Chrome asks for a password when trying to view all passwords. So it isn't _that_ easy.
Someone1234 7y ago
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. [0] https://stackoverflow.com/questions/2787853/arent-passwords-written-in-inputbox-vulnerable-through-a-stack-trace https://stackoverflow.com/questions/2787853/arent-passwords-...

tyingq 7y ago

Discussion about a demo of the issue... https://news.ycombinator.com/item?id=13329525 https://news.ycombinator.com/item?id=13329525

deleted 7y ago

[deleted]

smashah 7y ago

This also screws with notion to the point where I've largely stopped using it at all

albertzeyer 7y ago

Btw, at http://google.com http://google.com, this is what they have for the search field: <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 7y ago
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.

wolco 7y ago

As a developer this can be fixed by using unique field names.

phendrenad2 7y ago

I wonder what kind of engine overhaul Chrome is doing to cause all of these strange breakages.

platypii 7y ago

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.

robotstate 7y ago

I wrote a Medium article on how to actually turn it off 3 years ago that consistently gets about 500 views a week to this day.

mgoetzke 7y ago

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.

marcoseliziario 7y ago

So far this combinations seems to be working for me role="combobox" autocomplete="off"

marcoseliziario 7y ago

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"

aiCeivi9 7y ago

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.

iandanforth 7y ago

We're Google, we don't have to respect the spec.