4 ms·

What's the use case for not allowing autocomplete?

by d4rti 10y ago

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
      I used to solve this "security" feature by patching the Safari binary to ignore the attribute. Became too much of a hassle to chase that, but I seriously resent site developers who think they know better than I how I "should" be entering data on my machine. Seriously - a number of the complaints on both sides of the issue in this thread point to this. Running a lab and have a problem with autocomplete remembering passwords? That's should be a site-specific setting. Have a physical issue with typing, and use assistive software? The browser should have a setting to get out of the %$&^@*% way. Run your own machine securely (by whatever standards you choose to judge that)? It shouldn't be eBay's, or Apple's, or Google's decision how you choose to type your password. While I'm ranting, I'm seriously sick of a particular strain of arrogance mixed with refusal to take responsibility that emerges in these discussions. I recently had a discussion where a UX person confidently told me that they did, in fact, know better than I on a similar topic. OK, fine; here's a use case in which it seems that you're wrong. "Well, we can't cover every case; we have to plan for the 80% scenarios". You know my needs better than I, but refuse to take responsibility when you're wrong? Sounds like a good time to show a bit of humility and allow the user you apparently think so little of to make a choice.
      - arenaninja 10y ago
        I come off the opposite end, where this browser thinks it knows the data I want to enter better than I do. It doesn't. Neither do developers. I just want to use my browser plugin and ignore them both.
    - mikeash 10y ago
      For what it's worth, 1Password worked to log into eBay for me just now. Safari 9.1.1, 1Password 6.3.1. There does seem to be a bit of an arms race with some web sites, though, where the sites manage to break 1Password (whether intentional or not, I'm not sure) and then 1Password fixes it on their end. I wouldn't be surprised if eBay was broken and then got fixed.
      - CodeWriter23 10y ago
        Confirmed. Works for me now too. I must have been in one of those gaps in the arms race when I last experienced it.
micaeked 10y ago
A few devs posted their use cases here: https://bugs.chromium.org/p/chromium/issues/detail?id=587466 https://bugs.chromium.org/p/chromium/issues/detail?id=587466
realityking 10y ago
I've had massive problems with it for CRUD apps. Whenever you created a new user it would fill in the values from the first user you created on that system. Annoying as hell. The other problem - that we mostly managed to workaround - is that AngularJS and some browsers' autocomplete didn't go along very well.
winstonewert 10y ago
When you have your own javascript driven autocomplete that provides more accurate/context specific suggestions.
coderzach 10y ago
1) The default design of autocomplete makes your app look really bad. 2) There is an input for searching by name, email, etc. And you don't want it to auto fill with the users credentials.
vbcr 10y ago
Google's Search input field has autocomplete="off" setting. This is one of the popular use case I think.
wmil 10y ago
A field named 'email' isn't necessarily for your email. Apple has popularized the save field on edit model, so autofilling fields can potentially destroy data in a crud type app.
dimal 10y ago
If you have a field for the user to change their password, you don't want to autofill it with their current password.
snovv_crash 10y ago
OTPs. By definition they are different every time.
bcheung 10y ago
If the app expects the value of the field to be blank because that is what it was set to, then Chrome auto fills it, but it doesn't generate onChange events. So the app never knows the form has a value.
MildlySerious 10y ago
Not a use case, but Chrome bugs out when an input gets moved with CSS translate() and the autocomplete is open. The autocomplete stays in place unchanged while the input zooms off. Even if that wasn't the case, a well design form element that animates (transition in a game) looks very different to a deafault-autocomplete I can't turn off. This is taking away choice. No more.
edoceo 10y ago
The webhook form on github has autocomplete=off. Chrome prefills the hook URL with github username and the secret with my password. The browser is clearly doing the wrong thing.

What's the use case for not allowing autocomplete?

by d4rti 10y ago

What's the use case for not allowing autocomplete?

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
    I used to solve this "security" feature by patching the Safari binary to ignore the attribute. Became too much of a hassle to chase that, but I seriously resent site developers who think they know better than I how I "should" be entering data on my machine. Seriously - a number of the complaints on both sides of the issue in this thread point to this. Running a lab and have a problem with autocomplete remembering passwords? That's should be a site-specific setting. Have a physical issue with typing, and use assistive software? The browser should have a setting to get out of the %$&^@*% way. Run your own machine securely (by whatever standards you choose to judge that)? It shouldn't be eBay's, or Apple's, or Google's decision how you choose to type your password. While I'm ranting, I'm seriously sick of a particular strain of arrogance mixed with refusal to take responsibility that emerges in these discussions. I recently had a discussion where a UX person confidently told me that they did, in fact, know better than I on a similar topic. OK, fine; here's a use case in which it seems that you're wrong. "Well, we can't cover every case; we have to plan for the 80% scenarios". You know my needs better than I, but refuse to take responsibility when you're wrong? Sounds like a good time to show a bit of humility and allow the user you apparently think so little of to make a choice.
    - arenaninja 10y ago
      I come off the opposite end, where this browser thinks it knows the data I want to enter better than I do. It doesn't. Neither do developers. I just want to use my browser plugin and ignore them both.
  - mikeash 10y ago
    For what it's worth, 1Password worked to log into eBay for me just now. Safari 9.1.1, 1Password 6.3.1. There does seem to be a bit of an arms race with some web sites, though, where the sites manage to break 1Password (whether intentional or not, I'm not sure) and then 1Password fixes it on their end. I wouldn't be surprised if eBay was broken and then got fixed.
    - CodeWriter23 10y ago
      Confirmed. Works for me now too. I must have been in one of those gaps in the arms race when I last experienced it.

micaeked 10y ago

A few devs posted their use cases here: https://bugs.chromium.org/p/chromium/issues/detail?id=587466 https://bugs.chromium.org/p/chromium/issues/detail?id=587466

realityking 10y ago

I've had massive problems with it for CRUD apps. Whenever you created a new user it would fill in the values from the first user you created on that system. Annoying as hell. The other problem - that we mostly managed to workaround - is that AngularJS and some browsers' autocomplete didn't go along very well.

winstonewert 10y ago

When you have your own javascript driven autocomplete that provides more accurate/context specific suggestions.

coderzach 10y ago

1) The default design of autocomplete makes your app look really bad. 2) There is an input for searching by name, email, etc. And you don't want it to auto fill with the users credentials.

vbcr 10y ago

Google's Search input field has autocomplete="off" setting. This is one of the popular use case I think.

wmil 10y ago

A field named 'email' isn't necessarily for your email. Apple has popularized the save field on edit model, so autofilling fields can potentially destroy data in a crud type app.

dimal 10y ago

If you have a field for the user to change their password, you don't want to autofill it with their current password.

snovv_crash 10y ago

OTPs. By definition they are different every time.

bcheung 10y ago

If the app expects the value of the field to be blank because that is what it was set to, then Chrome auto fills it, but it doesn't generate onChange events. So the app never knows the form has a value.

MildlySerious 10y ago

Not a use case, but Chrome bugs out when an input gets moved with CSS translate() and the autocomplete is open. The autocomplete stays in place unchanged while the input zooms off. Even if that wasn't the case, a well design form element that animates (transition in a game) looks very different to a deafault-autocomplete I can't turn off. This is taking away choice. No more.

edoceo 10y ago

The webhook form on github has autocomplete=off. Chrome prefills the hook URL with github username and the secret with my password. The browser is clearly doing the wrong thing.