You are here

Firefox Password Manager Update: 2015-Q1

Logins are a part of our daily lives on the web and one of the active Firefox projects this year is to improve Firefox's password manager which has the simple high-level goal of helping users log in.

Here's a summary of the progress made in the first quarter of 2015 (in no particular order):

  • Telemetry – Probes (with the prefix PWMGR_) were added to gain a better understanding of how users were using the feature and to allow measuring the impact of improvements.
  • Ignoring @autocomplete=off in login forms – An autocomplete attribute with a value of "off" no longer disables auto-filling of login fields. This puts users back in control of their login experience and aligns with the direction of other browser vendors. Last year we started ignoring @autocomplete=off when deciding whether to ask the user to save/update their login so this is an evolution of that change. Note that @autocomplete=off is still effective outside login forms e.g. to implement custom search box autocompletion.
  • Capture doorhanger fields – The remember/update password doorhanger notification is now easier to visually scan with fields for the captured username and password. The username field is also editable which helps in cases where the detected username is incorrect or missing.
    Screenshot of the password capture doorhanger on Windows 7 in Firefox 39
  • Viewing and managing logins on Android – A password management interface (about:logins) was added to Firefox for Android and is accessible via the menu under Tools > Logins.
    logins list viewlogins context menu
  • Per-site recipes – A new mechanism was added to allow per-site overrides to the password manager capture and fill heuristics since it's not feasible/scalable to have general ones which work for every website. Initial recipe support allows overriding the username and password field detection via CSS selectors. There are only a handful of recipes currently in use as there hasn't been much focus/communication on gathering these yet but you're encouraged to file bugs about sites that don't work with the password manager (and if you're ambitious you can even submit patches to the JSON file).
  • Android Capture Doorhanger Polish – Capture doorhanger visuals were polished in preparation for later improvements.
  • General bug fixes – As usual, there were bug fixes for functionality that simply didn't work as expected. For example, Bug 1121040 regarding forms submitting via the Enter key during username autocompletion before a password had time to be filled in the password field.

Expect to see many more improvements in upcoming months as we continue to make major improvements to the password manager. If you'd like to contribute to this project, check out the password manager wiki page for mailing list, IRC, bug list and other information.


If you want to truly enhance the password manager you should implement a behavior Opera Wand like. Actually there's an extension that try to replicate it but it's not perfect.

Which specific aspects of Opera Wand are you interested in?
Automatic login (e.g. form submission) is not something we're currently working on as it's something that is quite hard to do reliably in general and part of the goal of this project is to improve the reliability of the feature and therefore the user's trust. Implementing a feature that probably won't work 1/10th of the time will likely work against that objective.
We are working on other UI improvements such as context menu items and an experimental UI (behind the pref signon.ui.experimental) to manually fill login forms for a page (but not submit them).

Since you now ignore autocomplete=off completely, have you also fixed the issue where it autofilled the wrong fields?

I remember in older versions of phpBB before they added autocomplete=off to the SMTP password field, the browser would automatically autofill the site password in the smtp password field in the admin ui, which is stored in plain text. This meant that every administrator could see the password of the administrator who last updated the configuration.

To clarify, we don't ignore autocomplete=off for non-login forms (i.e. not containing type=password) so one thing that works is not using type=password in some cases. Unfortunately there isn't a general, scalable solution but here are some thoughts:

  • We have bug 1168126 / bug 1119554 to do better on "registration" pages. I propose that we may be able to use a heuristic related to the types & number of fields present
  • We can add recipes to indicate which fields are not username/password fields for a site. Unfortunately this isn't super scalable.
  • We don't autofill into fields that have an existing value. Sites may be able to use this to avoid autofill. We also don't autofill a password if the detected username field doesn't match the saved logins.

I wish I had a better answer but I don't know a straightforward solution and autocomplete=off was being (ab)used to prevent auto-fill in the cases where it should work like simple login forms.

When can we expect an IE11/Edge like button to view the password in the input field?

I would also like such a feature but it's somewhat outside of the expertise of the team as it involves layout IIUC. Bug 502258 is the one to watch for this.
There are also a bunch of extensions implementing this functionality:

Why "2015-Q1" in the end of July?

Go ahead! Thanks!

Simply because I just got around to doing this and putting the whole first half of the year in one post would be too much.

Have you considered implementing a password generator for Firefox? For a first pass, right-click on a password field and choose "generate secure password" to generate a long random password.

Also, while I agree completely with disabling autocomplete=off, what should pages using password fields for other purposes use to say "this isn't a login form at all", don't fill it in? For instance, an administrator's user-creation form.

Yes, password generation is on the radar but can lead to a poor experience if the password manager heuristics and UI/UX fail the user at getting the generated password out of the password manager and into the form in the future. In order to avoid that poor experience, we decided to prioritize improving the reliability/accuracy and the UX (including alternate UIs) so we don't fail the user by having them locked out of their account where we generated a super-secure password. Once we have improved the password manager essentials we can come back to generation, especially when password sync is enabled. In the meantime, you can use one of the many Firefox extensions.

In order to markup a password field for a new account, the field should have the relatively new autocomplete="new-password" value. Firefox (like most other browsers) doesn't support this yet but it is the most correct way to do this. See bug 1119063 for my idea on how to introduce this with a password generator to prevent it turning into a replacement for autocomplete=off. Also see my reply to Jesper.

Would be great to see the password manager support U2F

Hello, see bug 1065729 for the current status. If you are able to contribute to this effort there are people willing to mentor.

All the changes made to password manager have noticeably improved usability and discoverability of this feature, especially for the non-tech folks who use Firefox. Keep up the good work.


Is the master password still encrypting the password store with 3DES? If so, any plans to move to AES? Further, is the encrypted password store encrypted with an authenticated MAC?

The future of a master password feature in Firefox is unclear. Here is a quote[1] from Justin Dolske, the owner of the password manager component:

It's generally agreed among UX/Engineering/Product that we don't want to further develop the existing master password functionality, as it's a poor fit for current needs and our current direction in this area."

Until we figure out what we want the feature to be, I don't think there will be any non-trivial improvements made to it.