See below re Chrome:
Part of the issue here is that autocomplete=‘off’ is overloaded. It is
simultaneously meant to denote a “secure” or “sensitive” field or that a
field’s completion will be handled by the application itself. Thus, we are
not proposing to ignore autocomplete=‘off’ for our form fill as there are
many places where the application itself creates a suggestion box, and we
have no desire to override that functionality. Rather, we care about the
“sensitive” use, which in the case of password fields, is already denoted
by the input type=‘password’.
autocomplete="off" either does or has until recently controlled both autofill and password manager on most browsers. The original intention behind the attribute doesn’t seem relevant - we’re not designing browsers - we’re making sites that work as users expect them to work in browsers that already exist.
IE 11 solved this issue by removing support for autocomplete=“off” on input type=password. RE: Passsword managers and autocomplete='off' from Adrian Bateman on 2014-01-03 (public-webapps@w3.org from January to March 2014)
And it sounds like from the above Chrome thread that Chrome either already has or is planning to do the same. I don’t know what Safari’s plans are. Didn’t look into Firefox.
What’s the value of adding autocomplete="off" to the password input?
Browsers either ignore it or use it to disable their built in password manager. None (that I know of) save your password without prompting - so there’s no risk of someone logging in on a public computer having their password inadvertently saved.
And if there is value to adding autocomplete="off" to the password field, is that value more than the cost of breaking the password manager for majority of mobile users? iOS Safari still looks to be around >50% of mobile browser share.
That’s a lot of Discourse users either picking insecure passwords they can remember or reuse or simply not logging in on mobile because it’s a hassle to copy and paste the password from Lastpass.