3 ms·

Password managers aren't nearly intelligent enough to be used without copy and paste for sensitive forms. One example is how almost every password manager incl

Password managers aren't nearly intelligent enough to be used without copy and paste for sensitive forms. One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username. So imagine a form like this: Amount to transfer: <input type="number"> From account ID: <input type="text"> Confirm password: <input type="password"> <button type="submit">Submit</button> I found that there's no good hackless way to allow a password manager to autofill the password without touching the other fields with a username or some other quirk like just clearing your inputs. Even a fix like opening a modal with the lone password confirmation field doesn't necessarily fix it in all browser/OS configurations. Password managers are braindead and browsers don't give you any tools to help.

DangitBobby 6y ago
I find that both Bitwarden (personal use) and 1password (work use) do a very good job of filling in login forms.
- hombre_fatal 6y ago
  1Password was one of my test extensions and the one I use every day. It works most of the time because username/password combos are the most common autofill configurations. So common that most password managers don't consider the case where you want to autofill a password without a matching username field on the page. "Password confirmation" being the classic example. They just don't handle anything other than the main case very well.
  - DangitBobby 6y ago
    Interesting. The weirdest site I use on a regular basis is Mailgun and it has this scrolling form which isolates entry for email/password/2fa (which, as an aside, I hate) and it gets it right every time. I can't remember any instances of it going wrong, actually.
Cldfire 6y ago
> One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username. Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill https://html.spec.whatwg.org/multipage/form-control-infrastr... > an input element whose type attribute is in the Text state that is followed by an input element whose type attribute is in the Password state > New autofill field name: "username" The intent isn't to pick a field far away in the DOM, though, so any autofill implementation doing that isn't being restrictive enough.
- asiachick 6y ago
  Yes, and the point of putting in the standard is so that it's documented how to author your website. Unfortunately, some not insignificant number of UI/UX designers want to push their special flow on users and so we get these incompatibilities. Hopefully the specs and expectations will evolve to the point that if your site doesn't follow the spec no one will use it. I can certainly imagine Apple/Google/Microsoft/Firefox having a semi-seamless sign up and failing to follow the standard means you plenty of users turn away
  - hombre_fatal 6y ago
    The spec is underspecified for basic edge cases, like any spec, and it's very hard to have implementation consensus. This stuff is supposed to improve the UX. Yet the reality is that even when building basic forms, every website has to test and solve the sort of problems shown in TFA. How much of the spec does every web developer in the world have to read to know that password managers should or shouldn't try to fill in credit card expiry/cvv in a hidden input? Does the spec even say anything about that? 1Password will ignore a `display: none`, by the way. Can this be quick-fixed by ensuring hidden inputs also have `display: none`? That's something every website trying to consider good autofill UX gets to figure out themselves if they even care. Unfortunately "just follow the spec" does very little to block off the rabbit holes you'll find if you try to perfect UX on even basic forms, else I might agree with you.
zwayhowder 6y ago
Lastpass used to have an option for autofill to only fill empty fields, not sure if it is still there as I moved on a year ago but it stopped a little of that annoyance.
3np 6y ago
You can still use something like passmenu[0] bundled with GNU pass, bind it to a hotkey and it fills it in as if you were typing on your keyboard, no clipboard involved. [0] https://git.zx2c4.com/password-store/tree/contrib/dmenu/README.md https://git.zx2c4.com/password-store/tree/contrib/dmenu/READ...

DangitBobby 6y ago

I find that both Bitwarden (personal use) and 1password (work use) do a very good job of filling in login forms.

hombre_fatal 6y ago
1Password was one of my test extensions and the one I use every day. It works most of the time because username/password combos are the most common autofill configurations. So common that most password managers don't consider the case where you want to autofill a password without a matching username field on the page. "Password confirmation" being the classic example. They just don't handle anything other than the main case very well.
- DangitBobby 6y ago
  Interesting. The weirdest site I use on a regular basis is Mailgun and it has this scrolling form which isolates entry for email/password/2fa (which, as an aside, I hate) and it gets it right every time. I can't remember any instances of it going wrong, actually.

Cldfire 6y ago

> One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username. Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill https://html.spec.whatwg.org/multipage/form-control-infrastr... > an input element whose type attribute is in the Text state that is followed by an input element whose type attribute is in the Password state > New autofill field name: "username" The intent isn't to pick a field far away in the DOM, though, so any autofill implementation doing that isn't being restrictive enough.

asiachick 6y ago
Yes, and the point of putting in the standard is so that it's documented how to author your website. Unfortunately, some not insignificant number of UI/UX designers want to push their special flow on users and so we get these incompatibilities. Hopefully the specs and expectations will evolve to the point that if your site doesn't follow the spec no one will use it. I can certainly imagine Apple/Google/Microsoft/Firefox having a semi-seamless sign up and failing to follow the standard means you plenty of users turn away
- hombre_fatal 6y ago
  The spec is underspecified for basic edge cases, like any spec, and it's very hard to have implementation consensus. This stuff is supposed to improve the UX. Yet the reality is that even when building basic forms, every website has to test and solve the sort of problems shown in TFA. How much of the spec does every web developer in the world have to read to know that password managers should or shouldn't try to fill in credit card expiry/cvv in a hidden input? Does the spec even say anything about that? 1Password will ignore a `display: none`, by the way. Can this be quick-fixed by ensuring hidden inputs also have `display: none`? That's something every website trying to consider good autofill UX gets to figure out themselves if they even care. Unfortunately "just follow the spec" does very little to block off the rabbit holes you'll find if you try to perfect UX on even basic forms, else I might agree with you.

zwayhowder 6y ago

Lastpass used to have an option for autofill to only fill empty fields, not sure if it is still there as I moved on a year ago but it stopped a little of that annoyance.

3np 6y ago

You can still use something like passmenu[0] bundled with GNU pass, bind it to a hotkey and it fills it in as if you were typing on your keyboard, no clipboard involved. [0] https://git.zx2c4.com/password-store/tree/contrib/dmenu/README.md https://git.zx2c4.com/password-store/tree/contrib/dmenu/READ...