1119063 - Don't autofill in password fields with an autocomplete field name of "new-password"

Status: VERIFIED FIXED

(Toolkit :: Password Manager, defect, P2)

Description

[Matthew N. [:MattN]]

<input type=password autocomplete=new-password> can be used to indicate that a password field is for the user to create a new password and therefore we shouldn't autofill/autocomplete a saved password in it.

Example use case: Prevent autofilling the administrator's password into the password field of a user edit page when changing some other detail about the user's account.

A risk is that it will be used to prevent autofill on login forms i.e. a new way to do @autocomplete=off that goes against the user's control

The above example could instead be addressed by having the username in a field with the autocomplete field name of "username" on the user edit page as we shouldn't be auto-filling the administrator's password when the username doesn't match.

Comment 1

[Dan]

While I welcome a way to prevent autofill for admin forms (see comments on bug https://bugzilla.mozilla.org/show_bug.cgi?id=917325), this bug seems very misguided.  First of all, the whole point of bug https://bugzilla.mozilla.org/show_bug.cgi?id=956906 was to prevent the site from disallowing autofill.  This would give that functionality back (as noted in the first post).

I think a better option would be to save the form "action" attribute along with the saved password, and ask the user if they want to autofill forms with different "action" attributes.  Or, alternately, you could autofill the form, having a notification that the form was "autofilled" and allow the user to say "undo and don't fill this form in the future" (and then blacklist the form by "action" value).

As password managers become more important, it would be a pity if web admins could prevent saved or autofilled passwords.  The user should be able to decide, on a form by form basis, if the autofill and/or saving of passwords will be allowed.

Vinnyjames in the other thread had a suggestion that somewhat mirrors my own thoughts.  The browser user should be in control.  He suggested notifying the user that the website does not want them to save their password, but allowing them to override that policy.  This lets the user know it is the website's fault, and not Fx's.  While this is a good idea, it does not solve the problem of admin forms being autofilled. I would take it one step further and notify (perhaps with "new-password") that "the website indicates this is a 'password reset' form and should not be autofilled with your current password--would you like to prevent this form from being automatically filled in?"  Perhaps a little too verbose for the average user...

Unfortunately we cannot rely on web designers to correctly use options that prevent saving of passwords.  Therefore, we cannot give them the options without allowing user override.  If we allow user override, we must provide an interface to deal with that.  Simply requiring a different attribute value for the same behavior doesn't solve the problem.

Comment 2

[Matthew N. [:MattN]]

I think if we implement password generation UI (bug 376674) on fields with @autocomplete="new-password" as soon as we start supporting that value then it will discourage sites from abusing it since it will lead to confusing UX for their users.

Comment 3

[Dan]

Hmm, that is a good point.  That's kind of a funny way of encouraging sites not to abuse it, but if that's the default behavior, it could actually work.

Comment 4

[florian.thoni]

Indeed, here we have a big issue with that behavior.
Let say we have an application (ttrss), that allow to subscribe to rss feeds, potentially private ones.
It has an option to add authentication on it. Those fields must remain empty if no authentication.

However, with this behavior they are automatically filled in with the user and password of the application itself that will be surely different of the target feed user/password and will send by curl this to an external site.

What do you recommend in such a case, if the team decide to continue to ignore that "new-password" directive ?

Thank you

Comment 6

[greg]

We use password fields to let users enter private info (potentially passwords) when running Jobs in Rundeck (http://rundeck.org).  Using 'new-password' allows us to prevent autocomplete.  This does not work in Firefox.  (see https://github.com/rundeck/rundeck/issues/2015 and https://github.com/rundeck/rundeck/issues/1966 )

There are many use cases where preventing the user's login password from autocompleting in a password field in a web application is desirable.

I think Firefox should behave the way Safari and Chrome do, and honor "new-password", to at least allow compatible behavior.

Safari pops up a small drop-down menu when you start typing in a username field, and lets you select whether or not to fill in the password, this is a smart compromise between doing it all the time and letting the user choose.

Ideally, I think password autocomplete should allow the user to select when and if to fill in the password.  For example: "Automatically fill my password on this site: [ ] always [ ] only this page [ ] never" or something similar.

Comment 7

[Steve C.]

(In reply to Dan from comment #1)
> First of all, the whole point of bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=956906 was to prevent the site
> from disallowing autofill.  This would give that functionality back (as
> noted in the first post).

I'd like to add a point of clarification. After reading the entire thread for bug 956906, I think it's safe to say that this isn't quite accurate. Manish G. partially summarized the change this way:
> This change makes it so that `autocomplete=off` does not stop the Password Manager from working.
> Normal form autofill can be disabled as usual.

Before him, Dave G. put it like this:
> For the eleventy billionth time, this change was only to allow the password manager to
> remember passwords at the request of the user.
> The autocomplete="off" flag is still intended to work for forms in general as it always has.
> The password manager and the form autocomplete systems are separate,
> and this bug was never about the later.

I think it's important to make the distinction clear here because I've been running into autofill issues with FireFox and, in most of the reading I've done to try and solve them, I've noticed people conflating the password manager with autofill and autofill with autocomplete.

I'm developing a B2B web app that gives admin from a particular business the capacity to associate their company's ConnectWise Manage credentials with all users from their business so that those users can import data about their clients and projects from ConnectWise. 

In order to capture those credentials, I've made a form that is similar to a user update form, but that instead updates data for all users associated with a particular business. This page has five input elements, each on its own row: Host, Company ID, Public Key, Private Key, and Your Password. The first three are type="text", but Private Key and Your Password both have type="password".

The problem I'm having is that the user login credentials saved in the password manager get loaded onto the page, despite whatever values I've set autocomplete to. Specifically, the username gets loaded into Public Key and the password gets loaded into Private Key.

I have no problem with users saving passwords for the app; I find it fairly convenient, myself. The issue here is that this isn't a login form; It's effectively a user update form, but one in which the first password field would almost never be any password that one would expect to be saved into the password manager, as it's not a password for the user's account, but the business's.

I recognize that maybe I'm not technically using the password field correctly in the sense that the private key isn't exactly an account password, but changing it to a standard text field just migrates the problem so that Private Key is treated as a username field and Your Password is treated (correctly, I suppose) as the password.

For me, setting Private Key to autocomplete="new-password" would seem to be an acceptable solution, provided browsers actually honored the setting.

Comment 8

[rugk]

Supporting autocomplete="new-password" would be really nice and has many legitimate uses, e.g. when a password input field does not belong to a login/register form.
Real-world examples would be a custom decryption password (https://github.com/PrivateBin/PrivateBin/issues/118) or a password used for HTTP Authentication in the backend (https://github.com/nextcloud/news/issues/122), where having a wrong (login) password filled in, could even accidentally expose the password to third-party sites or other parties depending on what is done with the password.
Also, this feature is implemented in all other mayor browser, so supporting it in Firefox would be a good idea.

Comment 9

[cby016]

Please add support for autocomplete="new-password". Other major browsers already support this and for compliance reasons we can't allow users to save passwords on our site. If this does not get fixed on firefox we will have to force our users to use Chrome, Safari or IE.

Comment 10

[rugk]

Actually your comment shows the big reason behind not adding this field. When you cannot do this "for compliance reasons" your compliance is broken and Firefox is doing exactly the correct thing: Not to allow this.
You *must not* disallow users to save passwords when they are real, good passwords. Saving passwords is a security feature. Password managers are a security feature. Feature, not bug! If you don't get this, you're doing something very wrong.
And you can't prevent users from doing t6his anyway BTW. They could always use a third-party password manager and/or just copy & paste the password or e.g. modify the HTML code with the browser's development tools.

And have a good attempt forcing your users to use other browsers. Haha…

So, @cby016, the fix you need is easy: Remove autocomplete="new-password". It makes no sense in your case.

Comment 11

[cby016]

If it were up to me I would allow users to save their password. Maybe you can tell the government that their "policy is broken" and they will change it. However until then we will have to direct our users to other browsers that do support this feature. That actually shouldn't be a problem since only about 5% of our users are using Firefox.

From what I understand, autocomplete="new-password" is part of the standard, and all major browsers support it except Firefox. I thought Firefox was a standards compliant browser.

Also @rugk, 2 months ago you posted in favor of implementing this feature. I'm not sure why you posted such a condescending response to my post that is asking for the same thing.

Comment 12

[rugk]

LOL, only 5% of your users are Firefox users. In this case you don't need to worry…
Because I was asking for a legitimate use case. To clarify:

Legitimate:
* as the name implies: for setting a new password
* passwords, which actually are not login passwords and make no sense to be stored.

Not legitimate:
* Forcing users to nopt store passwords.

Comment 13

[lastresort]

This feature should be implemented.

Our software allows the admin to create new users. If you store the password you'll always get yours filled into the fields for the new name and password. Also there's a configuration site where you're able to configure smtp data. You always get the password field and another field which isn't even a username field filled by fault because of autocomplete. If you don't notice that before you save the config it leads to a wrong configuration which affects our software.

I guess there are many other cases in which ignoring this flag ends up in very bad user experience.

Sure, it also can be used for "not legitimate" cases, but if the user notices such a case he could simply don't use the site anymore.

In total I'd say you do more harm than good to the user by ignoring this flag.

Comment 14

[gulty]

Not allowing new-password is doing more harm than good. There are so many usecases where you can login as an admin and manage other users. If passwords are prefilled you can (if you do not pay attention to the autofill) change a users password when saving by mistake. If you want to activate a feature in a users account for instance. Or adjust anything else in the user profile.

Overall it's not a good idea to assume that the login credentials are valid/wanted for all types of password fields on a site. This is simply a wrong behaviour. For most sites it might be a good thing but for CMS or other business sites you cannot assume that this is the default behaviour.

You need to implement a way for the developers to avoid the autofill for places where it's not supposed to take effect and for places where it's simply wrong and would make the user experience worse!


+1 for adding "new-password" according to the standards. Firefox doesn't have to be the only exception where this is not working.

Comment 15

[Kacper]

I can't believe this is not yet implemented. I am having HUGE issues with a CRM system where admins have power to reset users' passwords by typing them manually into a password-type field.

Unfortunately, the password reset field is not normally visible (it is hidden from view by JS). Because of lack of support for autocomplete="new-password", whenever an admin edits a user's record, that record's password gets updated to admin's own password. This is a HUGE isssue that has now forced manual processing of hundreds of records on us. As a result, we are now having to ban Firefox from being used with the CRM.

To stress once again: a "password"-type field serves also other uses than for the current user's account password. In real life, it is used to store hashes, keys, ids, and so on. Autofilling it with a user's password is a bug.

Comment 16

[roelharbers]

According to https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields :

"If an author would like to prevent the autofilling of password fields in user management pages where a user can specify a new password for someone other than themself, autocomplete="new-password" should be specified, though support for this has not been implemented in all browsers yet."

Guess which browser hasn't implemented it yet...

Currently, I'm having issues with a page where the user can set his own password (using a password reset link): because there's no username field (which wouldn't make sense, because a guid in the link determines the username), the password manager just puts the username into the nearest input before the password field, which happens to be an otp field in my case.

How do I tell Firefox that this is, indeed, NOT a login screen?

Comment 17

[roelharbers]

To add: This is basically my password reset page:

https://jsfiddle.net/2eazsvqt/4/

the password manager seems to assume the otp field is the username because reasons. Reloading then fills the otp field with that stored "username"

My solution is to add a hidden input just before the password field, which tricks firefox into filling that field with the "username" instead of the otp field:

https://jsfiddle.net/2eazsvqt/6/

Surely this cat-and-mouse stuff shouldn't be the way forward here.

Comment 18

[John Hascall]

It seems to me that there are two separate issues.
(1) Saving an entered password, and
(2) Filling in a saved password.

I have recently been working on our (self-service) username registration page.
(1) I would be thrilled if people are using a password manager to save the password they enter, but
(2) I *really* don't want the password they are using somewhere else to be filled in (perhaps the only password they ever use, ugh)!

So my suggestion would be that autocomplete="new-password" can (ask to) save the password (1), but will not autofill into that field (2).   If there is still worry that web designers will "abuse" this feature, I suppose you could remember the exact url and the id of the field and only autofill on an exact match.

Comment 19

[Sami Leino]

You still haven't implemented this? This is ridiculous. Browser is echoing login credentials into management forms, and you think that's the way it should be? Web developers inject extra username/password fields into forms and hide them when document is loaded just to get FF to populate those dummy fields instead and leave the real fields empty as they should be, when creating new users for example.

Comment 20

[RedScourge]

I figured out how to bypass this Marxist "give all the power to the user even if they're an idiot who always clicks yes and slowly corrupts your password database as a result" stuff that Mozilla has done by ignoring web standards here. 

Just create multiple useless username and password fields, hide them from the user, and then even if they choose to save passwords for this site, and are too stupid to figure out how to change that decision, it doesn't matter, because your code is discarding the username and password that they're saving anyway. This basically kills autocomplete and the password manager in one fell swoop. 

If you need to also kill autofill, just add an additional hidden field with a random token, and have the legitimate username and password field be the one with that token in its name, that way your processing script can look for the fields with that random token in the name and know that this is the legitimate field, and the rest are garbage.

Comment 21

[Keith Maika]

Running into this issue currently while implementing a user add/edit page which includes the ability to change the user's login information.

I think a good solution here would be to make a field with autocomplete="new-password" act the same way as a password field does when there are multiple logins saved for the same site.  In this situation, when the field is focused a small popup appears displaying each saved username and when selected the field is populated with that username's login.

This approach means that the field is not pre-filled so accidental submissions are avoided, but still allows a user to easily auto-fill the form limiting the potential for sites to abused it as a means of preventing password manager user.

Comment 22

[RedScourge]

A good solution would be anything which somehow requires the user to actively do a non-default thing, rather than making the browser callously override the almost certainly deliberate intentions of the web developer by default. Preferably, in a way where it isn't anything resembling a default option, as there are countless millions of users who seem to just assume that they have to click whatever "Ok" option gets in their way without reading it, in order to get where they want to go. 

That way, everyone gets what they want; the developers get some semblance of expectation that their code will do what it is supposed to do unless the user goes out of their way to override it, users who know what they're doing get to override it in the unlikely event they want to, and everyone else who doesn't much care to do so gets the developer's intended user experience.

Comment 23

[woranl]

I don't see a point not implementing the autocomplete="new-password" standard. This will only make developers life miserable and not improve any security what-so-ever. As a developer, if I really want to force this to work, I just create multiple dummy password field above my password field, and set them visibility:hidden. The password will be fill to the dummy and my password field with autocomplete="new-password" will work as intended. I always found Mozilla sometime has a weird design choice when it comes to things like this. It almost feel like folks are too egocentric and the design choice is driven by politics more than anything else.

Comment 24

[jonlennryd]

Hi, I work with a web-based-system used in schools where the computers are shared. It means the same student does not have their own computer but instead are given a computer or sometimes an iPad at the beginning of the class.

The problem of auto-completion becomes quite obvious in this scenario! The login page should not have autocomplete, neither the edit user account form. The teachers are not always aware of the security issues and do not disable any password-storing functionality in the browsers. On top of this students, on the other hand, are very aware of how to 'hack around', and can easily change settings in a browser, which might remain until next class. 

I would like to be able to completely disable auto-completion on both passwords, and username-fields. We have already misused Chromes autocomplete="new-password" to at least disable the possibility for another student to change other students passwords during class! ;)

Comment 25

[Laurențiu Nicola]

@jonlennryd You can use different OS accounts, or at least the policy support (about:policies#documentation and Google) to disable the password manager.

Comment 26

[gulty]

@jonlennryd: for your purpose IMO you are wrong here. You should be disabling autofill in the browser settings and restrict the access to them. Or let everyone create an own user account.

Comment 27

[RedScourge]

(In reply to Laurentiu Nicola from comment #25)
> @jonlennryd You can use different OS accounts, or at least the policy
> support (about:policies#documentation and Google) to disable the password
> manager.

Do you mean going to about:config and changing values? because "about:policies#documentation" doesn't work in the latest version of Firefox. 

I would assume that perhaps one could set defaults to false to disable autofill, correct? Is there a way to do this via AD Group Policy in Windows though, so that a sysadmin doesn't have to log on to every computer in their organization as every user and change this option manually in order to ensure this functionality is disabled? Because if not, this is pretty much an insufficient solution for corporate environments, which one would assume is probably the main sort of environment where it may be useful to disable this functionality.

Comment 28

[Laurențiu Nicola]

(In reply to RedScourge from comment #27)
> Do you mean going to about:config and changing values? because
> "about:policies#documentation" doesn't work in the latest version of
> Firefox.

It should work AFAIK (I'm on Nightly). Try about:policies instead.

> I would assume that perhaps one could set defaults to false to disable
> autofill, correct? Is there a way to do this via AD Group Policy in Windows
> though, so that a sysadmin doesn't have to log on to every computer in their
> organization as every user and change this option manually in order to
> ensure this functionality is disabled? Because if not, this is pretty much
> an insufficient solution for corporate environments, which one would assume
> is probably the main sort of environment where it may be useful to disable
> this functionality.

https://support.mozilla.org/en-US/products/firefox-enterprise
https://support.mozilla.org/en-US/products/firefox-enterprise/policies-enterprise
https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig

They do have a set of ADMX templates, which should be enough. You can also deploy a policies.json file, or even override about:config preferences.

---

Also, if you care about security, don't share accounts between professors and students. You're just one keylogger away from compromising everyone's credentials.

---

Since this was kinda off-topic, here are some thoughts about the requested feature. If it's implemented, it *will* be abused by special snowflake websites like seen in comment 10. If you want security for your users, implement a form of two-factor authentication like TOTP, don't trick the browser to disable its password manager. I'd rather user per-site randomly generated passwords than a single password everywhere, because I don't trust some of these snowflakes to care about KDFs and password salting. And it's *my* browser, so keep your hands off it.

As for the "legitimate" use case, is having to delete or replace an auto-filled password such a hassle? I'm sure there might be users who have trouble with that, but that's something inescapable. You probably have other features these users are having trouble with, so you still need a way of supporting them.

Comment 29

[jonlennryd]

Thanks for all the links and info! 

Reality sucks though, as many schools do not have any security personnel worth its name. Also, a school is a bit different world than the normal internet world, since the one sitting next to you can snatch your iPad for a moment and make a mess, just for the fun of it. That's the "use case" we are thinking about in general, because it happens from time to time. With the password autocomplete turned off, a typical change-password-page would not allow a stranger to change your password. (as it requires you to enter your old password, which in this case are auto-completed by the browser)

I agree it is a pretty specific problem, and it can be fixed simply by turning off the password vault in the browser. On the other hand, it surprises me there is no way for a webpage-maker to simply opt out of password auto-completion. I understand the discussions, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=956906 makes sense. It is just that all these discussions assume each person have their own computer/pad which they have full control over.

Comment 30

[RedScourge]

Really what would be an optimal solution would be if a new type=obscuredtext option and a new type=username option were added to the HTML standard, and thereafter type=username and type=password would become the standard field types for web developers to use for login form username and password values, and the standard field types to trigger browser password managers. This would free up everyone from the confusion of knowing whether a given type=text field is supposed to be a login form username, 
and whether a given type=password field is supposed to be for a login form password or if the web developer had some other intended purpose to obscure a field.

This solution would allow there to never be any doubt in the minds either of web developers or browser developers what the intention of these form field are, and which form fields the password manager may/should attempt to use and which it should not. While having the added bonus of making HTML more semantically intuitive, and the added bonus of eventually allowing browser developers to remove the code which tries to figure out which text field to treat as a username whenever a password field is present in a given form, most importantly it would completely prevent a potential arms race between web developers who may want a particular obscured text field to not trigger the browser's password manager for some reason, and browser developers wanting to trigger the password manager on every form containing a type=password field in case a user might want it to, regardless of any problems caused in certain applications.

It would however be difficult and time consuming to get everyone else on board with altering the HTML standard accordingly, so a good compromise would probably be to implement the already existing and increasingly supported autocomplete=new-password functionality instead.

Comment 31

[goodoldgrim]

This is such a misguided arms race. I will create the password field at runtime with a random id and obscure the input with JS that hides characters as they are typed and stores them in memory, if necessary, but if I decide a field is not getting autofilled, it's not getting autofilled.

Same as others, I have nothing against password managers - my use case is an admin form.

The only sane solution is a notification that the web page is blocking autocomplete of that field and an option for the user to override it. Then the control is still with the user and programmers who just want an obscured field not to get autocompleted can go about their day without this inane hassle.

Those who want to disable password managers will find a way. The arms race is a waste of everyone's effort. It should be focused on educating people about benefits of password managers instead.

Comment 32

[Matthew N. [:MattN]]

You can get the parsed @autocomplete value with input.getAutocompleteInfo().fieldName

Comment 33

[Sam Foster [:sfoster] (he/him)]

I'm thinking that we probably want a new AUTOFILL_RESULT for the autocomplete=new-password case. That way it fits the existing logic in _fillForm and if I'm reading this correctly we also get telemetry for this outcome. Is there any issue I'm missing with just creating a AUTOFILL_RESULT.PASSWORD_AUTOCOMPLETE_NEW_PASSWORD or something like that?

Comment 34

[Matthew N. [:MattN]]

That should be fine and would be a good idea.

Comment 35

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1119063 - Don't autofill password fields with autocomplete=new-password. r?MattN

• Add form autofill outcome AUTOFILL_RESULT.PASSWORD_AUTOCOMPLETE_NEW_PASSWORD
• Autocomplete behavior is not changed

Comment 38

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32c7dc092efd
Don't autofill password fields with autocomplete=new-password. r=MattN

Comment 40

[Andrei Ciure[:aciure]]

Backed out changeset 32c7dc092efd (bug 1119063) for failing test_autocomplete_new_password.html

push that caused the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=230887270&revision=32c7dc092efda4c745b4b1fe3590249d0d0513df

failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&fromchange=45e6c58d067134a2fad0a9de9e1fe94c68401087&selectedJob=230874188&searchStr=android%2C4.3%2Capi16%2B%2Cdebug%2Cmochitests%2Ctest-android-em-4.3-arm7-api-16%2Fdebug-mochitest-60%2Cm%2860%29

backout: https://hg.mozilla.org/integration/autoland/rev/03d6fa61c83594e678952a3f8bc275e9b5e3a614

Comment 41

[Sam Foster [:sfoster] (he/him)]

Thanks for the backout. I've re-submitted it with that test skipped for android.

Comment 42

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0cb8b8db9618
Don't autofill password fields with autocomplete=new-password. r=MattN

Comment 43

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/0cb8b8db9618

Comment 44

[Daniel Bodea [:danibodea]]

The password fields with autocomplete="new-password" will not autofill while the password fields with autocomplete="off" will autofill as intended. in Nightly v68.0a1 and Beta v67.0b4.

Tested using the following test page:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
</head>
<body>

<form method="POST" action="./">
  <h1>Single password field has name="new-password"</h1>
  <p>
    <input type="password" autocomplete="new-password">
  </p>
  <p>
    <input type="submit" value="Login">
  </p>
</form>

</body>
</html>

Does this cover everything? I don's see if there could be any edge cases that might need testing? Are there?

Comment 45

[Matthew N. [:MattN]]

You could test configurations like a password change form:

• current-password or no @autocomplete
• new-password
• new-password

Comment 46

[Daniel Bodea [:danibodea]]

I have also tested the new-password and confirm-password fields form from changing a Google, Yahoo and Reddit account's password. These fields are not being auto-completed.

In the case of the Reddit "update your password" form, the current (about to be changed) password field was auto-filled and this is expected, while the "new password" and "verify password" fields are not being auto-filled.

Based on all the above, this issue is now considered verified in Nightly v68.0a1 and Beta v67.0b5.

Comment 47

[Rob Wu [:robwu]]

Docs needs to be updated:

https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields

If you are defining a user management page where a user can specify a new password for another person, and therefore you want to prevent autofilling of password fields, you can use autocomplete="new-password"; however, support for this value has not been implemented on Firefox.

This is already documented at https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete , but I don't see any browser compat table on that page.

Comment 48

[Chris Mills [:cmills]]

We also have a dedicated page for the autocomplete attribute — https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete — but this is also lacking in the usual browser compat/specs information. We'll fix this in the next cycle.

Comment 49

[Chris Mills [:cmills]]

Note added to Fx67 rel notes: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/67#HTML

Comment 50

[Matthew N. [:MattN]]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #49)

Note added to Fx67 rel notes: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/67#HTML

This bug is about autofill, not autocomplete so I updated the text to reflect that. We will still offer the password in autocomplete to deal with sites who abuse this value since we ignore autocomplete="off". Feel free to re-word it.

Comment 51

[Chris Mills [:cmills]]

This bug is about autofill, not autocomplete so I updated the text to reflect that. We will still offer the password in autocomplete to deal with sites who abuse this value since we ignore autocomplete="off". Feel free to re-word it.

Ah, I misread that — thanks for the clarification :MattN! I have tweaked the note slightly; looks fine now.

Comment 52

[Chris Mills [:cmills]]

OK, so I think the docs are done for this one.

I've updated the autocomplete page to include an example, specifications, and browser compat data section. I also made sure the wording looked good:
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete

I submitted a PR to add the actual compat data to our repo:
https://github.com/mdn/browser-compat-data/pull/4108/files

Finally, I updated the wording in the following section (as recommended by :robwu, thanks for the pointer!):
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields

Let me know if the wording looks ok - thanks!

Comment 53

[Matthew N. [:MattN]]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #52)

OK, so I think the docs are done for this one.

Thanks!

I've updated the autocomplete page to include an example, specifications, and browser compat data section. I also made sure the wording looked good:
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete

I'm not sure if this was an existing issue but the autocomplete attribute isn't only for <input> like the page says/implies a few times.

Comment 54

[Chris Mills [:cmills]]

I'm not sure if this was an existing issue but the autocomplete attribute isn't only for <input> like the page says/implies a few times.

This is a good point. I've updated the wording accordingly throughout the article to take into account textarea and form elements too.

Comment 55

[Rob Wu [:robwu]]

Could you link to the new compat table from the last paragraph at https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields , so that readers can know which browsers support "new-password"?
The current article doesn't link to the autocomplete documentation at all, so the information is not easy to find.

Comment 56

[Chris Mills [:cmills]]

(In reply to Rob Wu [:robwu] from comment #55)

Could you link to the new compat table from the last paragraph at https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields , so that readers can know which browsers support "new-password"?
The current article doesn't link to the autocomplete documentation at all, so the information is not easy to find.

Done; I've added a general link to this page higher up too.

Comment 57

[Rob Wu [:robwu]]

And to make the cycle complete, could you link to The_autocomplete_attribute_and_login_fields from the "new-password" section of the autocomplete docs? There is already a notice at "off", but given the detail in that separate page, linking to it from "new-password" seems useful too.

I should have mentioned that in my previous comment; I hope that spreading it over two comments did not inconvenience you.

Comment 58

[Chris Mills [:cmills]]

(In reply to Rob Wu [:robwu] from comment #57)

And to make the cycle complete, could you link to The_autocomplete_attribute_and_login_fields from the "new-password" section of the autocomplete docs? There is already a notice at "off", but given the detail in that separate page, linking to it from "new-password" seems useful too.

I should have mentioned that in my previous comment; I hope that spreading it over two comments did not inconvenience you.

No worries at all! Link added to the "new-password" value entry.

Comment 59

[Matthew N. [:MattN]]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #54)

I'm not sure if this was an existing issue but the autocomplete attribute isn't only for <input> like the page says/implies a few times.

This is a good point. I've updated the wording accordingly throughout the article to take into account textarea and form elements too.

You forgot about <select> which I have now added.

Comment 60

[Chris Mills [:cmills]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #59)

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #54)

I'm not sure if this was an existing issue but the autocomplete attribute isn't only for <input> like the page says/implies a few times.

This is a good point. I've updated the wording accordingly throughout the article to take into account textarea and form elements too.

You forgot about <select> which I have now added.

Ah, thanks, appreciate it. I missed it because it wasn't listed in the list at https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes; I've added it there too.

Comment 61

[smith]

(In reply to RedScourge from comment #30)

Really what would be an optimal solution would be if a new type=obscuredtext
option and a new type=username option were added to the HTML standard, and
thereafter type=username and type=password would become the standard field
types for web developers to use for login form username and password values,
and the standard field types to trigger browser password managers. This
would free up everyone from the confusion of knowing whether a given
type=text field is supposed to be a login form username,
and whether a given type=password field is supposed to be for a login form
password or if the web developer had some other intended purpose to obscure
a field.

This solution would allow there to never be any doubt in the minds either of
web developers or browser developers what the intention of these form field
are, and which form fields the password manager may/should attempt to use
and which it should not. While having the added bonus of making HTML more
semantically intuitive, and the added bonus of eventually allowing browser
developers to remove the code which tries to figure out which text field to
treat as a username whenever a password field is present in a given form,
most importantly it would completely prevent a potential arms race between
web developers who may want a particular obscured text field to not trigger
the browser's password manager for some reason, and browser developers
wanting to trigger the password manager on every form containing a
type=password field in case a user might want it to, regardless of any
problems caused in certain applications.

It would however be difficult and time consuming to get everyone else on
board with altering the HTML standard accordingly, so a good compromise
would probably be to implement the already existing and increasingly
supported autocomplete=new-password functionality instead.

How would an 'obscuredtext' type be different to honouring autocomplete="off" on password type fields?

The real problem is that browser developers have decided that preventing websites from disabling autofill on login pages is more important than honouring the correctly expressed semantics of well built web pages.

Just posting my 2 cents since I ran into this issue on my application. My developer's solution was to add hidden fields that get autofilled instead of the 'real' fields and I'm not happy with that.

Comment 62

[Intermittent Failures Robot]

199 failures in 779 pushes (0.255 failures/push) were associated with this bug yesterday.

** This test has failed more than 150 times in the last 21 days. It should be disabled until it can be fixed. **

Repository breakdown:

• autoland: 199

Platform and build breakdown:

• gecko-decision: 2
  • opt: 2
• linux64: 5
  • asan: 1
  • opt: 2
  • tsan: 1
  • debug: 1
• windows2012-64: 3
  • debug: 1
  • opt: 1
  • asan: 1
• android-5-0-x86_64: 4
  • debug: 1
  • opt: 2
  • debug-isolated-process: 1
• lint: 7
  • opt: 7
• osx-cross: 3
  • opt: 1
  • debug: 1
  • plain: 1
• linux1804-64: 2
  • opt: 2
• windows2012-32: 2
  • opt: 1
  • debug: 1
• linux1804-64-qr: 85
  • debug: 65
  • opt: 20
• macosx1015-64-qr: 6
  • debug: 3
  • opt: 3
• windows11-32-2009-qr: 3
  • debug: 2
  • opt: 1
• windows11-64-2009-qr: 5
  • debug: 3
  • opt: 2
• android-em-7-0-x86_64-qr: 3
  • debug-isolated-process: 1
  • debug: 1
  • opt: 1
• linux1804-64-tsan-qr: 5
  • opt: 5
• android-em-7-0-x86_64-lite-qr: 1
  • opt: 1
• linux1804-64-asan-qr: 62
  • opt: 62
• windows11-64-2009-asan-qr: 1
  • opt: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1119063&startday=2023-06-14&endday=2023-06-14&tree=all

Comment 63

[Natalia Csoregi [:nataliaCs]]

Removing the [stockwell disable-recommended] tag as it was caused by a spam user starring jobs against this bug.
Sorry for the inconvenience!