A change in password manager

In my last post I talked about how password manager currently works. Starting in Firefox 26 (assuming all goes well), it will work a bit differently.

Currently, the password manager must look at each page that loads, and process it to see if it might be a login page (and if so try to fill in a saved username/password). This is kind of dumb and has always annoyed me. For one, it’s not really great for performance. We spend a small amount of time to do this on every page, when only a tiny fraction of pages will actually be login pages. Nor is it suited to the modern web — many pages do interesting things after they’ve initially loaded, but the password manager only attempts to do its work at initial page load. If a page dynamically adds a username/password field to the DOM afterward (in response to, say, the user clicking a “login” button), we never notice and thus can’t offer to fill in a login.

Starting with tomorrow’s Firefox 26 nightly build (or the day after, depending on how merges and build go), this whole process will instead be triggered when an <input type=password> is appended to the DOM — be it from loading static HTML, or when the page dynamically adds one later. This means password manager can skip processing most page loads (i.e., the ones without password fields). It also means it can now fill in logins on some sites that it couldn’t before.

This new functionality comes via bug 355063, with major supporting work from bug 771331 (which added the chrome-only DOMFormHasPassword event) and bug 839961 (which refactored password manager to prepare it for using this event). It’s also interesting to mention that bug 762593 has already added code to use DOMFormHasPassword, in order to log console warnings when a page is using password fields insecurely.

There is one potential downside.

This changes the timing of when passwords are filled, so if a site is setting or clearing the contents of login fields, it’s possible it could blow away a login that previously hadn’t been filled yet. For example, I’ve seen sites clear fields as a poor security measure (I guess to deter password managers?), as well as set fields (to values like “Enter username here”). The latter is a great example of when and why the HTML5 placeholder attribute should be used.

I don’t think this change is a significant risk, and is definitely worth it for the other benefits. But should you run across it, there will be a signon.useDOMFormHasPassword pref that can be flipped to revert to the old code. (This is only a temporary pref, it will go away once we’re sure this isn’t a big problem.) And, again, if you find problems please file a bug containing debug info.

4 thoughts on “A change in password manager”

  1. Why not just use the new behaviour but then re-fill it when the last of the onload event handlers returns?

    That way, I’d be able to click “submit” as soon as the form appears and use the password manager on AJAX-loaded password forms but, if the site is doing foolish things with onload or onDOMComplete handlers, it’d still get overridden in the way the old behaviour does.

    I could imagine it being a just a little hairy if the user has saved a password and starts typing a different username and password combo before a slow-to-load page finishes loading but, if the site code decides to muck up the new password manager’s approach to things, that’d already be an iffy scenario. (And a proper solution would be as simple as watching the fields in question for keypress and paste and setting some kind of “dirtied by user. don’t overwrite” flag.)

  2. I often find the password not prefilling when I expect it to. Maybe these ideas are not in scope for this change, but any of the following would be awesome:

    * Logging to the console when you get a “near miss” – so if you are on https, and the site has data for http, the log would say “not prefilled; https: version is available but site is http” or “not prefilled; this publicsuffix+1 has four username/password pairs for other domains”.

    * A right-click “Smart Prefill Password” option which looks for suitable info from any site in the same publicsuffix+1 domain. This would deal with www. vs bare, www. vs login., http vs. https and so on.

    I also often find it doesn’t offer to save the password when I want it to, and it’s not always due to autocomplete=off. Is there debug logging that could clue me in as to why?


  3. I enjoyed the last 2 blogs, was on something I wanted to know about.
    Could you write up on how firefox handles password encryption. I am very interested in knowing something about that especially in the context of how chrome’s password handling came into the limelight recently

Comments are closed.