1274304 - Inputs to enter a new password should not have autocompleted values in them

Status: RESOLVED DUPLICATE of bug 1119063

(Toolkit :: Password Manager, defect)

Description

[randy]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.5.17 (KHTML, like Gecko) Version/9.1 Safari/601.5.17

Steps to reproduce:

Our Web UI has the following HTML to allow the user to change his existing password:

<input name="newPassword" required autocomplete="off" type="password"/>



Actual results:

The user's stored password is used to autofill the input.  This input is being used to choose a DIFFERENT password, so we don't want the existing one filled in.  Even more confusing, passwords are stored with an associated userid, but this form does NOT contain any input that matches the userid stored in the password manager.

This bug is due to a poor decision made in bug 956906, based on an incorrect assumption about the behavior of other browsers like IE 11.  IE 11 does not exhibit the same behavior, nor do Chrome/Safari.

In general, type="password" only means that the input's text should be obfuscated, and NOT that it should contain the user's current login password, ESPECIALLY on a form that contains no other inputs in which the user could enter the userid associated with the stored password.


Expected results:

When autocomplete is set to off, honor it like the spec says.

Comment 1

[randy]

BTW, "sites that think password managers are harmful" can still avoid this "Mozilla knows best" behavior by placing a hidden password input before the real one, so 951981 achieves nothing other than to break real-world use cases and to escalate the "don't store my users' passwords" perceived war.

Comment 2

[Matthew N. [:MattN]]

This will be fixed by autocomplete="new-password" in Firefox 67+

Example:

<input required autocomplete="new-password" type="password"/>