Autocomplete="off" disables Safari password manager


(Larry Salibra) #1

The username and password input fields on Discourse have the autocomplete="off" attribute which disables Safari’s password manager (aka iCloud Keychain).

Lastpass seems to ignore this attribute.

Details: http://www.appleqa.co.uk/q/answers-how-to-make-safari-remember-my-password-for-sites-where-autocomplete-off-59979.html


(Michael Brown) #2

This is arguably a fault in Safari - the autocomplete attribute is meant to control autocomplete, not a password manager:


(Larry Salibra) #3

See below re Chrome:
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/1002.html

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.


(Jeff Atwood) #4

You make a good point! Maybe we should remove this next week @neil?


(Larry Salibra) #5

Do you want a pull request for this?


(Jeff Atwood) #6

Sure that’d be great! :trophy:


(Larry Salibra) #7

It turns out that the password manager works fine on iOS Safari if you enter the password once on the phone. It’s remembered and filled in on subsequent visits. (but only on mobile not desktop)

Can’t tell from the code where the autocomplete is coming from.


(Jeff Atwood) #8

I see a few places, bootbox.js, chosen.jquery.js, and the ace editor. Bootbox seems possible for the password form?

But then again, I tried going to the login form on try.discourse.org and I don’t see that autocomplete attribute on the password field in the first place?

<tr>
<td>
<label for="login-account-password">Password&nbsp;</label>
</td>
<td>
<input id="login-account-password" class="ember-view ember-text-field" placeholder="" type="password"> &nbsp;
</td>
<td>
<a id="forgot-password-link" data-ember-action="87">I forgot my password</a>
</td>
</tr>

(Neil Lalonde) #9

I tried this today on Safari 7.0.3 and on iOS 7.1.1. It worked for me. On desktop, I got these prompts:

And of course I had to enable the feature (which I normally don’t):

So… Works On My Machine™?


(Jeff Atwood) #10