12 ms·

“autocomplete=off is ignored on non-login input elements”

• jaitsu 10y ago
  I ranted about this on my blog whilst drunk, and then went off in a tangent, you can find it at jameshalsall.co.uk, 2nd post. This really makes me uncomfortable, standards are there for a reason, you don't just ignore them because you don't agree with them.
  • Karunamon 10y ago
    And sometimes the standard is wrong. The page telling the browser that the user isn't allowed to auto fill a form puts too much control in the hand of the page.
    • DanBC 10y ago
      Sure. Fix the standard, don't just make shit up. Maybe the standards process is broken, in which case that's something that needs fixing. I can't see why the four browser makers can't create their own browser standards.
      • lallysingh 10y ago
        You often need in-the-field experience with a proposed change before it's considered.
      • dreamdu5t 10y ago
        Standards are just made-up shit. Most of them are formalized descriptions of what people were already doing before the standard existed. Correct me if I'm wrong, but no browsers have formally committed to adhering to the standards.
        • wang_li 10y ago
          > Correct me if I'm wrong, but no browsers have formally committed to adhering to the standards. Don't know about that, but they certainly like to brag about the size of their standards compliance penis.
      • matt_kantor 10y ago
        That sounds like what they're doing. > We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2] > [2] https://html.spec.whatwg.org/multipage/forms.html#autofill https://html.spec.whatwg.org/multipage/forms.html#autofill In my opinion the new spec is overly-complicated and will probably not be followed by web developers, but on the other hand a binary "on"/"off" choice was way too blunt of an instrument. I don't know how the authors of the original autocomplete spec didn't see this coming.
      • dragonwriter 10y ago
        > Fix the standard The standard is that autocomplete attribute can be used to hint to the user-agent how to apply any autocomplete functionality it has. The standard is not that the UA must provide autocompletion when it is "on", or must not do so when it is "off". So, I don't see any problem with the standard and Chrome's behavior.
        • kuschku 10y ago
          Actually, the standard says that "on" is a MAY, but "off" is a SHOULD.
          • dragonwriter 10y ago
            Yes, and neither is a MUST.
          • zardeh 10y ago
            SHOULD is not SHALL.
  • saulr 10y ago
    The standard is only a hint to the user agent, not a MUST.
    • kuschku 10y ago
      Except, it is a SHOULD.
  • zimpenfish 10y ago
    > standards are there for a reason > you don't just ignore them because you don't agree with them People always ignore the bits of the standards they don't agree with; taking an entirely dickish and non-random example e.g. <img src="http://secure.gravatar.com/avatar/df0e70f6e810442b86d701afcb193249?s=120"> http://secure.gravatar.com/avatar/df0e70f6e810442b86d701afcb... https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/ says "4.8.4.1.1 Except where otherwise specified, the alt attribute must be specified and its value must not be empty" Or having 4 <section> but only 3 </section>.
• raldi 10y ago
  Good. It's my browser. I get to turn its features on and off, not you. And that goes double on my phone. As a compromise, I'd accept a prompt like: +---------------------------------------+ | This page recommends we disable | | autocomplete. What do you think? | |[Okay] [Fuck them; autocomplete anyway]| +---------------------------------------+
  • taf2 10y ago
    99% of the time I agree but imagine for a second a user management system that lets an administrator edit other users profiles and a browser that decides to autocomplete the email fields in the form or name etc... Better hope auto save is not a thing... Of course when it comes to buying things online give me my autocomplete or I hate you - love your recommendation for a browser prompt!
    • iamdave 10y ago
      imagine for a second a user management system that lets an administrator edit other users profiles Just my $0.02, and this might be taking us out of the scope of discussion (maybe not?) but I can't think of a good business reason why an administrator needs to control whether or not the end user can use a function like autocomplete. That seems like micromanaged minutiae that will annoy my users more than help them if it's something they rely on for data entry. And if that's the case...why bother touching it in the first place? Training/security policy that says "Be mindful of how you use this feature" to avoid any awkward NDA/HR situations? Sure, absolutely 100%. Curious what others think on this?
      • jroblak 10y ago
        You've completely missed the point of the comment. Your parent was describing a system where an Administrator edits other users' data. If that Administrator is using Chrome while editing a user, then there is no way to disable autocomplete, and the browser may fill the user's form fields with the Administrator's information resulting in bad data.
• arenaninja 10y ago
  > "The problem is that autocomplete='off' is far more often used for poor reason than good." Wow. I think Chrome is jumping the shark on this one. EDIT: It seems I have angered the Google employees on HN. I have but one acronym: KISS. Have the standard adjusted or adhere by it
  • doctorshady 10y ago
    Wow, not even anybody asking you to explain your reasoning. So it's okay when Google ignores standards, but not Microsoft?
    • arenaninja 10y ago
      It's ridiculous, the comment is even flagged. I watched it in fascination yesterday as it oscillated between 0 and -2 points.
• Gracana 10y ago
  Is there ever a reason to honor that setting?
  • matthewcford 10y ago
    A valid reason is a search field, on a shared system where you do not want it to autofill with past searches.
  • wiredfool 10y ago
    * One time password fields. * Admin pages for dealing with users * CC virtual terminals * Any time that the data being collected is about a third party.
  • kuschku 10y ago
    If the site has its own autocomplete?
  • JoshTriplett 10y ago
    The original motivation for autocomplete=off came back when Mozilla had a small market share and Firefox and Chrome didn't exist. Some major bank websites blocked Mozilla by User-Agent. When Mozilla and Mozilla users got in contact with those banks, the banks demanded the ability to block autocomplete for their login forms. Several times afterward, when people wanted to fix autocomplete, the banks had an effective veto with "we'll block you". At the time, Mozilla didn't have nearly enough market share to say "no, that's our users' decision". See https://bugzilla.mozilla.org/show_bug.cgi?id=63961 https://bugzilla.mozilla.org/show_bug.cgi?id=63961 for the history.
• edoceo 10y ago
  This causes many problems for app devs to work around this broken policy. StackOverflow is full of silly tricks from field naming to odd JS. Wasting time
  • d4rti 10y ago
    What's the use case for not allowing autocomplete?
    • CodeWriter23 10y ago
      Getting 25% fewer users to continue through the funnel. https://news.ycombinator.com/item?id=11911434 https://news.ycombinator.com/item?id=11911434
      • arenaninja 10y ago
        Very nice, except when you have something that is explicitly not a conversion funnel. Admin functionality being a big one
        • CodeWriter23 10y ago
          This is the use case where the web page should not interfere, thereby enabling the user to use their password manager. You can't even log in to eBay using 1Password any more. That's ridiculous. Perhaps what is needed is autocomplete="secure" where the browser will only autocomplete after challenging the user for a master password.
          • arenaninja 10y ago
            I prefer to use LastPass for password/form autocomplete, and disable the browser's autocomplete entirely. This enhancement just encourages me to use Chrome less. It looks as though I'm in the minority here, however
          • __jal 10y ago
• zbowling 10y ago
  I fully support the decision by Chrome. I hate when forms try and force it off and get me to type the same thing over and over. It's an abused attribute.
• tetrep 10y ago
  I see this as a good thing. Far better to streamline password management than to make it bumpy, encouraging users to use memorable passwords, which most likely will also be painfully weak. It's a good and sane default.
• wiredfool 10y ago
  I'm trying autocomplete='sudo-off' now. It's not really semantic, but it does get across my intention. (in this case, a new user form designed for a current admin. Sometimes the site developer really does know more than the browser)
  • JungleGymSam 10y ago
    I think you mean "pseudo".
    • timv 10y ago
      No, he meant "sudo" https://xkcd.com/149/ https://xkcd.com/149/ http://www.explainxkcd.com/wiki/index.php/149 http://www.explainxkcd.com/wiki/index.php/149
      • JungleGymSam 10y ago
        Seems like a stretch of a joke.
        • Sylos 10y ago
          It would make more sense, if you were familiar with the Unix command line. Pretty much whenever something tells you "Permission denied", you just retype the same command with "sudo" before it and then it does what you want. And yeah, that definitely happens often enough to be a running joke among Unix users.
• CodeWriter23 10y ago
  "We announced during the Chrome Dev Summit in 2015 that when Autofill is enabled we see 25% more forms submitted than when it's disabled [3]." In other words, 25% more users will make it to the next stage of your conversion funnel if autofill is permitted.
  • Animats 10y ago
    That's a reason to turn on autocomplete in your signup form, not to force it on in the browser.
    • CodeWriter23 10y ago
      That would be a negative user experience, given the prevalence of legacy forms on the web. Example: "Why does this autocomplete feature fail most of the time?"
  • notatoad 10y ago
    "and of you're using a form for something other than a conversion funnel, well screw you"
• deleted 10y ago
  [deleted]
• Someone1234 10y ago
  I'm going to side with the Chrome team on this one. There's very few occasions when autocomplete being disabled makes sense, the vast majority are just developers dumping it in there because they want to make doubly-sure the user actually entered a field by hand (e.g. email addresses) and often for vaporous reasons like "Improve Data Quality," "Stop Spammers/Bots," and "Make sure the user enters the right data in the right box." Ultimately if you want to assure data quality then use data or format validation, or verification (e.g. send an email with link). If you want to stop bots/spammers use captcha. We did go through a period where people were "misusing" standard input boxes for other things and autocomplete would ruin that extra usage. But hopefully we've moved beyond turning an input box into a richtextbox using a complex array of hacks, and can now instead use things like Canvas. PS - Hopefully they disable "smooth scroll" scripts next. So tired of having my scrolling ruined by "helpful" sites.
  • mrweasel 10y ago
    >There's very few occasions when autocomplete being disabled makes sense True, perhaps. The point is that's not for Google to decide. In their example with CRM system, it's very possible that the developer did think about it, and decided that autocompletion would "help" the user enter wrong data. Now Chrome forces you to be non-compliant to work-around to their "custom feature". Chrome is increasingly encouraging developer behaviour that's reminiscent of Microsoft and Internet Explorer 6.
    • timdierks 10y ago
      It's not for the developer to decide any more than the browser. It's up to the user.
      • wmil 10y ago
        Except there's no ability for the user to disable autosave on a page specific basis. So if autocomplete breaks functionality then there's nothing the user can do if the developer assumed autocomplete='off' would continue to work. Except disable autocomplete on every site, which is kind of overkill.
• koolba 10y ago
  > As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field. Reminds me of the good old days of making things work with IE6. > Again, thanks to everyone for your comments. We look forward to continuing the conversation. Sure you do. Then why is commenting closed?[1] [1]: See the "Restricted- Only users with EditIssue permission may comment." box on the left pane.
  • md224 10y ago
    > Sure you do. Then why is commenting closed? From the post: > All this said, we're still learning. So we would like to better understand your use cases for setting autocomplete=off. To have that conversation in a more focused manner, I've created a new bug: crbug.com/587466. We're going to try and keep that conversation focused and productive, so we want to avoid "+1s" and the like. I'll be closing this bug in the meantime. Commenting is open at https://crbug.com/587466 https://crbug.com/587466.
    • koolba 10y ago
      Ah! Well that's what I get for skimming through the post. I stand by the IE6 comment though.
  • deleted 10y ago
    [deleted]
  • edibleEnergy 10y ago
    'The semantic meaning' hack is bad for readability. You don't actually mean 'new-user-street-address' you mean 'do not autofill this input chrome.' The next developer in will assume the semantic meaning accomplishes something, and decorating your markup with things that may or may not do nothing seems is bad practice.
• _Codemonkeyism 10y ago
  Some years ago we had trouble with autocomplete. Browsers would fill in credit card details and customers would call us where we've got their credit card details from. Or they we're completed into a different website and people called us why we gave the other website the CC details.
• donatj 10y ago
  I actually find this particularly annoying working for a service aimed at elementary schools. Our user base is almost entirely shared desktops / Chromebooks in schools. Not all school admins are smart enough to disable password saving / autocomplete (not to mention not all schools have someone for this) so we see cases of a kids account getting misused because it was saved on some library desktop all the time. Give users the option to opt out, but taking the power out of the app developers hands by default is short-sighted.
  • gmazza 10y ago
    What you raise is a valid concern, but letting websites decide on enabling/disabling auto-complete is solving it entirely wrong way around. If local admin is incapable of configuring user accounts, how are websites supposed to figure out who is who, and which browser is on shared computer? After all, if managing user accounts is too hard for said admin (or we are talking about a shared PC in a library, which doesn't have user accounts as a matter of principle) - just make browser always start in private/incognito mode on shared computer. It is as easy as adding command-line argument "--private-window" for firefox or "--temp-profile" for chrome. That's it. Window closed - autocomplete gone. Problem solved.
    • arenaninja 10y ago
      Assumes a competent, dedicated local admin is on staff. This is not the case at about 75% of the SMBs I've come into contact with over the past two years
      • acdha 10y ago
        Modern operating systems have a guest mode which doesn't preserve state across sessions - if they cannot manage something this easy, everyone should be using a guest login.
    • kalleboo 10y ago
      Websites will always have the ability to disable auto-complete though. Just now it will be though a series of ever-increasingly insane hacks found on StackOverflow (culminating in a custom JavaScript textfield with broken accessibility/internationalization)
• Arzh 10y ago
  I was wondering why my Pizza Hut login process got a lot smoother.
• avodonosov 10y ago
  Horrible. There are cases when autocomplete="off" is necessary to improve user experience. It's sad that such policies are defined by people not familiar with web development enough to know such cases. Also, some forms will become inconsistent when autocomplete="off" is ignored (radio button filled by autocomplete instead of the value specified by developer, but the related text input field is disabled as specified by developer). Moreover, it's a standard. Everyone was complaining about Microsoft when it introduced non-standard HTML and Javascript semantics. Now Google does that.
  • michaelmior 10y ago
    Are there any cases which can't be handled by autocomplete="okay-google-really-off"?
    • Analemma_ 10y ago
      It'll be amusing if this creates an arms race where Google ignores more and more autocomplete values, until someone just makes an Apache/nginx extension which just gives them a random value.
      • HappyTypist 10y ago
        Chrome 60 will now calculate the entropy of the value, and if it appears to contain more entropy than typical strings it will ignore the value and whack the programmer on the head.
    • IanCal 10y ago
      Turning it off in other browsers? What do other browsers do when they don't understand the setting? If any of the others say "well it doesn't say off, so let's leave autocomplete on" then you're a bit screwed.
      • Sylos 10y ago
        Considering how the entirety of web development works, you could probably just include both values and then the browsers would figure out themselves which one they want to listen to.
• skynetv2 10y ago
  i love autocomplete and i hate when the page tries to turn it off for no logical reason. I have an extension installed that forces autocomplete on for everything.
• gmazza 10y ago
  Good riddance. Now can we please start ignoring: onpaste="return false;"
  • rogerbinns 10y ago
    There is a chrome extension for that (NSFW name) https://chrome.google.com/webstore/detail/dont-fuck-with-paste/nkgllhigpcljnhoakjkgaieabnkmgdkb https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
    • artursapek 10y ago
      Banking websites do this. I cannot stand it. Thanks.
      • rogerbinns 10y ago
        It is like they want to prevent people from using password managers and strong lengthy passwords!
        • josho 10y ago
          In some cases because their legacy systems can't support long passwords. I know my previous bank was restricted to 6 digits (maybe even just 4). Their solution was to add in those annoying security questions like "What was your first dog's name". Sigh.
          • roywiggins 10y ago
            I use Diceware for those things, in case I have to use them over the phone. "My dog's name is effervescent mandible egg voldemort; my mother's maiden name is regent utterly busted harpy"
        • jrockway 10y ago
          I called Schwab once because a LastPass misstep locked me out of my account. The CSR told me it was great that I was using a password manager and that she wished more people used them. I guess it keeps her employed ;) But on a more serious note, banks are not as stupid and anti-technology as the average HN reader wants to believe. Their programmers are no doubt here too. (Now why Schwab limits me to an 8 character password... I don't even want to know. But I do have a _good_ 8 character password ;)
• jrochkind1 10y ago
  > We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2] https://html.spec.whatwg.org/multipage/forms.html#autofill https://html.spec.whatwg.org/multipage/forms.html#autofill Okay, aside from what you think about being unable to just turn off autocomplete, those semantic tabs actually sound super useful, and i hadn't known about them. > As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". Um, "new-user-street-address" does not appear in the list of recognized values from the WHATWG spec that was linked to above. How do we find the list of values that Chrome actually recognizes and what they mean? Am I missing it somewhere else? How does Chrome expect devs to use something completely un-doc'd?
  • timdierks 10y ago
    You elided the relevant sentence: > In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it. They're saying that they don't autofill when they see autocomplete values which Chrome doesn't recognize, so if you don't want autofill, they suggest you just put in a description of what this field is, which won't be recognized. The functionality is the same as if you put in autocomplete="foobarbazquux", but it's better-described.
    • jrochkind1 10y ago
      Ah, thanks, I didn't do it on purpose, I was just confused. Because: > our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it. How is a value not allowed by the spec "valid" as they say? They're encouraging you to violate the spec to trigger chrome-specific behavior (can't really say what other browsers will do when spec is violated, can you?), really? Or does the spec say you're allowed to make up new values too? i don't _think_ so, but maybe I missed that part (not being sarcastic).
• wnevets 10y ago
  ignoring standards worked for IE.
• merb 10y ago
  Google's own Search field: <input class="gsfi" id="lst-ib" maxlength="2048" name="q" autocomplete="off" title="Suche" type="text" value="" aria label="Suche" aria-haspopup="false" role="combobox" aria autocomplete="both" dir="ltr" spellcheck="false" style="border: none; padding: 0px; margin: 0px; height: auto; width: 100%; position: absolute; z-index: 6; left: 0px; outline: none; background: .... oh.... autocomplete="off" and autocomplete="both" really strange.
  • xrstf 10y ago
    One is `autocomplete`, the other is `aria-autocomplete`.
• Scryptonite 10y ago
  It's tough to say that Chrome made the right call, as I enjoy being able to (in theory) rely on browsers aiming to be standard compliant. The standard is there for a reason, no? I noticed that the Chrome team also developed a feature called Threaded scrolling in an attempt to improve site UX, but instead (or additionally?) completely ruins the ability to rely on onscroll/onmousewheel events (let alone being able to trust the values pulled from scrollLeft/scrollTop using requestAnimationFrame or similar). This can be seen on these two GIFs, with threaded scrolling enabled (currently the default behavior): https://gfycat.com/DiligentHomelyIndianelephant https://gfycat.com/DiligentHomelyIndianelephant and with threaded scrolling disabled (behind a chrome flag): https://gfycat.com/SlimDefinitiveErin https://gfycat.com/SlimDefinitiveErin The same flag/feature is active on mobile Chrome as well, so the same effect can be seen. The only way to guarantee jank-free work with scroll position (for parallax or w/e) is to implement handling user-input-to-scroll-behavior entirely yourself, which is rather unfortunate imo. You can play with this yourself: http://jsbin.com/mohehotupe/edit http://jsbin.com/mohehotupe/edit (might need to click "Run with JS" / or tick "Auto-run JS" to start the scroll-listening script) My take on autocomplete is that the standard says it's something I can disable, so autocomplete="off" is simply something the browser should obey. I have no problems with users using extensions or taking "advantage" of a browser setting to "fix" websites they say have abused this attribute. But there are valid use cases for disabling autocomplete as other comments have mentioned, and all they have done is make it to where I just have to do autocomplete="sudo-off" and it "works". But what happens when other webmasters misuse the attribute again? Might as well just toss support for it if they really can't trust the page to do the right thing.
• abalone 10y ago
  It's not just Chrome. Safari[1], IE and even Firefox[2] haven't respected it either for quite some time. [1] http://stackoverflow.com/questions/22636673/safari-saved-passwords-are-overriding-autocomplete-off-in-forms http://stackoverflow.com/questions/22636673/safari-saved-pas... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=956906 https://bugzilla.mozilla.org/show_bug.cgi?id=956906
• pbreit 10y ago
  Probably best for the 99%. I suppose for the 1% they could consider a flag?
  • rocky1138 10y ago
    Good idea. What if we include an attribute in the form itself. I propose "autocomplete" You can set it to "on" or "off" depending on your needs.
• growt 10y ago
  I think it is necessary for some fields to have autocomplete="off" for PCI compliance (login/password field if I remember correctly). So this creates the interesting situation where I should set autocomplete to something else so that chrome doesn't complete it, but that would result in a failed compliance check.
  • WildUtah 10y ago
    Yes. PCI is a silly substitute for actual security. But the alternative is that many banks and their partners will run with no security because bank executives as a class are firmly opposed to sharing authority with competent IT security people. This is one cost of their class solidarity.
• Dylan16807 10y ago
  I have some pages with passwords but not usernames, and chrome keeps trying to treat it as a login, picking an arbitrary nearby field as username, and ignores all markup suggesting otherwise. It's on my todo list to figure out something that bypasses its stupidity, like setting it to a normal field with a weird font, as it's not necessary to prevent copying out of the field.
• Jordrok 10y ago
  This is one of the few cases where I'm actually in favor of Chrome's rogue behavior, though I think they're probably doing it for the wrong reasons. I've been annoyed one too many times by webpages that refuse to allow me to autofill login credentials from my browser, to the point where I had to keep a js bookmarklet to strip that attribute from every element on the page. I always hated that it took such a hacky solution to do something which is so simple, and resented sites that attempted to take that ability away from me. So to me, any change which puts control back in the hands of the user is a good one. I suspect though that the motivation is mostly to "increase engagement" rather than to empower the user.
• josteink 10y ago
  Google Internet Explorer. Might as well adopt the name now, rather than later.
• zeta0134 10y ago
  I've noticed that a great deal of secure websites will disable autofill in their username and password fields on purpose. For ages I've had a Chrome extension installed that disabled autofill=off to get around exactly that, and I believe I'll leave it enabled. I know better than to trust plain password auth anyway, and mostly use the feature to remember one-time passwords to things like forum sites that have the ridiculous policy of hiding plain URLs to non-registered users. (I will never understand what a forum gains by having a large number of users in their database who registered once to download that one attachment, then never came back again.) Regardless of the intent, I think when you try to make decisions on behalf of your users, you're doing them a disservice. I mean, really, the security risk of autofill on password fields is that the user's passwords are now saved on their computer? I think users who need to utilize this feature and have it denied them will just end up typing the password into a word document named "Passwords.docx," and that's a heck of a lot less secure than Chrome's encrypted password store. Not that Chrome's implementation couldn't be better, but still.
  • WildUtah 10y ago
    Why use a Word document? I put all my security passwords—especially the ones that won't autoflll or that make me change them often—into a Google Docs spreadsheet online. That way I can get to my passwords from anywhere.
• marktl 10y ago
  Trusting users over developers will lead to less security overall. In this case it will make providing intranet access to employee owned devices a little less secure or less user friendly (by blocking chrome)
• lucb1e 10y ago
  Firefox has been doing this for quite some time now: https://bugzilla.mozilla.org/show_bug.cgi?id=956906 https://bugzilla.mozilla.org/show_bug.cgi?id=956906
• gkoberger 10y ago
  Here's a huge reason why this is bad. Our company let's you set a "global password" to lock your site. Chrome was auto-filling the password site silently, and exposing people's personal passwords to their whole team when they saved. I understand wanting control, but... Sometimes this is horrible behavior.
  • acdha 10y ago
    Why isn't that a bug in your application? Unless you're building a password manager, passwords should never be shown to someone else. If you need the ability to let multiple people do things, they should still perform the action using their private credentials so you'd have accurate records for who initiated the action.
    • gkoberger 10y ago
      No, it's an outward facing password to preview non-live sites, like Shopify or Squarespace have. More of a beta code than a password.
  • marcosdumay 10y ago
    Why don't you use, you know, a password field for entering that password?
    • gkoberger 10y ago
      We did, which caused the problem. (We had a "show password" option, but even if we didn't, it'd still be visible in the HTML)
• JungleGymSam 10y ago
  > As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field. Seems reasonable to me.
  • kuschku 10y ago
    Except, Google themselves now do "google-chrome-autocomplete-off" and "both" and similar values instead. We just replicated the PHP or IE situation with mysqli_real_surely_this_time_it_works_escape_string or autocomplete="sudo-off".
    • dragonwriter 10y ago
      > Except, Google themselves now do "google-chrome-autocomplete-off" and "both" and similar values instead. That's clearly a suboptimal practice by Google's web team. Which doesn't make Google's Chrome team wrong, but maybe the latter should have a word with the former.
      • kuschku 10y ago
        Well, there’s no alternative. You don’t want the Google search box, or the hidden textfield in Google Docs, or so, to autocomplete.
        • dragonwriter 10y ago
          > Well, there’s no alternative. Sure, there is. You could do a meaningful semantic autocomplete tag that isn't one of the recognized ones, rather than a variant of "no, really, don't autocomplete this". (Actually, "body" is probably not a bad practice, but the other one was.)
• frandroid 10y ago
  > In cases where you really want to disable autofill Dude, we've already told you.
• bcheung 10y ago
  So many ugly hacks are needed as a consequence of this. I know what I want my app to do better than you Chrome. Please don't purposely break the Internet. When I try to do user management. I can't call the fields `username` or `password` because Chrome will attempt to autofill it with the saved user/pass from the login. So annoying. :( Also, it doesn't trigger onChange events when it gets autofilled. :( This breaks Angular because the field's value is different from what Angular thinks the field's value is.
• Kiro 10y ago
  Isn't a chat a better and more common example than a CRM system? You don't want to autocomplete your old chat messages.
• xemdetia 10y ago
  It feels like the solution here is to have a serious-business flag for chrome like phabricator does. Is the browser working for me or is it just helping me work for someone else? That seems to be the real intent problem here. I feel for all the CRM types and data entry people that are going to struggle with this. The user may decide that they don't want autocomplete for a page but they may not be sophisticated enough to turn it off in a meaningful way, or for a particular site. I still think it's really troublesome that it invents a user-side data store of potentially sensitive data that they really had no say in.
• djcapelis 10y ago
  Good. It's taken far too long for user agents and web standard to remember that the intent of a user agent is to be an agent for a user, not something that an external server can dictate with pixel perfect precision.
• vmarsy 10y ago
  I'm not very familiar with autocomplete behavior, but does this work across domains? on hidden fields? Would this help <malicious website> or even <legit website but with malicious tracking intents> to extract information without my consent?
• leepowers 10y ago
  How is this going to work with honeypot fields? Chrome will autocomplete hidden fields like this: <div style="display: none;"> <input type="text" name="phone"> </div> Where "phone" is the honeypot field. Not shown in-browser, so usually only a bot will fill out the honeypot field, sending a strong signal that the form is an automated/spam request. Of course, autofill messes this up. So the more correct implementation is to turn it off: <div style="display: none;"> <input type="text" name="phone" autocomplete="off"> </div> But if an autofill of "off" is ignored this technique will no longer work, as the user's browser will fill in the honeypot field.
  • Strom 10y ago
    Based on the OP you would use: <div style="display: none;"> <input type="text" name="phone" autocomplete="honey-phone"> </div> The way I understand it, it's not that autocomplete can't be turned off, it's that "off" no longer turns it off. You can still turn it off in plenty of other ways.
  • tracker1 10y ago
    Another possibility would be to add two fields dynamically via JS at load, the first populated at load with a timestamp when the form was loaded... then add onkeyup/onfocus/onclick events for the other form fields, and when triggered populate the second field with the current timestamp. From there, you can compare the numbers, offset from the current time, and do other checks. I mean, you might want to allow for up to an hour of drift, but most people won't sit on a page for an hour then hit submit. Though it would be circumvented easy enough, if it's custom, would worry less about it. Also... <div style="display: none;"> <input type="text" name="phone" autocomplete="section-honeypot nofill" /> </div>
  • wvenable 10y ago
    It's ok, most bots are smart enough to avoid invisible fields. This probably hasn't worked in 5 years.
• zimbatm 10y ago
  If you follow the link to the next discussion it quickly becomes pretty clear that it's a bad idea: https://bugs.chromium.org/p/chromium/issues/detail?id=587466 https://bugs.chromium.org/p/chromium/issues/detail?id=587466 Anyone who has to fill forms for other people is going to end up putting his own personal information into the fields by mistake.
• zimbatm 10y ago
  The one that I wouldn't mind changing is when the site somehow blocks pasting a password into the field. Yes, I'm not typing it because I use a password manager thank you very much!
• grandalf 10y ago
  Google isn't the new Microsoft, it's the new Halliburton.
• xg15 10y ago
  The rationale for ignoring autocomplete=off makes sense to me. What I don't understand at all is the suggested "workaround" for disabling autocomplete: > In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. [...] As an example, if you have an address input field [...], you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field. So essentially they encourage authors to make up random, nonstandard values for the attribute that may or may not do what the author is hoping for. I don't see what this will archieve except making the autocomplete attribute a pain to use in practice. (Which might be what the Chrome team intends, but even then, a more straight-forward and more honest way would be deprecation.)
  • djrogers 10y ago
    > they encourage authors to make up random, nonstandard values for the attribute No, they are encouraging you to give more meaning to your fields. For the example given of a CRM app, using customer_email_address as the input field makes much more sense than using a standard value for email address, as the two fields are asking for different things: The latter always wants your email address, whereas the former wants the relevant email address for the record you're viewing/editing.
    • xg15 10y ago
      But there is no guarantee all sites will use the same values or even give the values the same meaning: One might write "customer_email_address", another "e-mail-address-of-customer". A third one has separate input fields for the parts before and after the "@" and uses "email-address-name" and "email-address-host" respectively... So in the end, if everyone followed the advice and used "semantic" values, this would likely lead to the same problems that HTML already had with semantic class names, rel values and meta tags. The discussions about them fill mailing list archives. I don't see why all this should be repeated, even more so as the problem of semantically annotating your elements is already solved. But in this case it's even weirder as that was presented as a way to tell Chrome "please don't autocomplete". So if that's the real motivation, then sites are likely to just put some variant of "really-really-off", or just random strings in it without any regard to "semantics".
• ComodoHacker 10y ago
  >In the WHATWG standard, we defined a series of new autocomplete values ... "language" "bday" "bday-day" "bday-month" "bday-year" "sex" "url" "photo" I can't resist the feeling these were specifically developed by the User Data Mining department.
• djrogers 10y ago
  Chrome, IE11[1], and Firefox[2] all do this, and have for a while. [1] IE11 does not support the attribute at all http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0015.html http://lists.w3.org/Archives/Public/public-webapps/2014JanMa... [2] Firefox ignores it too https://bugzilla.mozilla.org/show_bug.cgi?id=956906 https://bugzilla.mozilla.org/show_bug.cgi?id=956906
  • dragonwriter 10y ago
    Both of those apply just to ignoring autocomplete settings for password management, not other input fields. That's different from Chrome not giving effect to autocomplete=off for any fields.
• jmcnevin 10y ago
  Would you ever want autocomplete on, say, a field where you're inputting a 2FA response? Probably not, since any suggestions would be useless. I find the workaround of "just put some other random bullshit for the value" hilarious. And once developers start over-abusing that as well (they will), then what's the plan?
• kevin_b_er 10y ago
  One of the commenters on the linked bug to discuss valid use cases for autocomplete=off hits a wonderful nail on the head: > Actually there is a famous site called http://www.google.com http://www.google.com they use autocomplete="off" for their search form since every time you visit the site you want to search something completly different.
• geuis 10y ago
  I wish I had been able to find this a few weeks ago. Was working on a modified login feature where the autocomplete behavior was actually a hinderance to a UX improvement we were working on.
• byuu 10y ago
  Not making a comment either way on whether they should be doing this, but ... I think we all know what's going to come next :( //add random number to stop Chrome from disabling autocomplete //--number is stripped off in form processing routine print "Address: <input type='text' name='address--" . rand() . "'>";
• tacone 10y ago
  How long before somebody uses that to guess your physical address by creating a page with input field named 'address' and so on just to read their values with JS?
  • aphextron 10y ago
    The problem is you can't read autofill values with JS. This leads to a horrible experience for users when you have say an Angular form that gets autofilled and they click submit and it tells them the form is missing data.
    • angry-hacker 10y ago
      But would it be possible to send the values using ajax to server side?
    • tacone 10y ago
      Disappointing. I don't use Chrome, so for me it's difficult to even believe such thing is possible
• mindcrime 10y ago
  For the love of FSM, why is it that browser vendors are always so f%!#ng arrogant?? It's not just Chrome, we've seen this attitude from Firefox devs before as well: "fuck you, we know more about what you meant than you do". I really wish somebody would fork either Chromium or Firefox and commit to delivering a browser that just fully, completely and accurately implements the various specifications, instead of trying to "improve" them like this.
• Nitramp 10y ago
  I wrote this extension a long time back: https://chrome.google.com/webstore/detail/docomplete/onlplldgmkgpoangfokimmikjheamnfb?hl=en https://chrome.google.com/webstore/detail/docomplete/onlplld... It removes "autocomplete[off]" from all input elements.
• carn174s 10y ago
  Pretty sure that Satan's minions invented auto-complete as a vector for side channel crypto vulnerabilities.
• jrochkind1 10y ago
  The weird thing is, `autocomplete=off` _does_ seem to have the intended effect on my Chrome. OSX 50.0.2661.102. Huh? Was this change made in a later version I haven't gotten yet?