Currently Login Manager performs password autofill by waiting for the DOMContentLoaded event, and processing any forms seen then. This works well for most sites, but some (most notably Digg) have a "login" link that just floats a JS-generated form over the current page. No only do we not autofill that (since the form is created after pageload), but we don't even attach the autocomplete bits to the form.
It would be nice to have content generate events whenever a password field is created (it has a little bit of code already to kickstart loginmgr via notification when the *first* password field is ever created). Login Manager could then hook into that, so it would work on any password field no matter when/how it's created.
This would also allow pwmgr to get out of the main pageload path -- we wouldn't have to look at every page, and could just look at pages with password fields.
In addition to Digg, this should also help with Hotmail / Windows Live login pages.
One idea for implementing this is to observe the creation (well, DOM insertion) of password fields, probably via a new notification fired in nsHTMLFormElement::AddElement(). There's already some old code there for initializing pwmgr.
This has a few other benefits as well... We could toss out the WebProgressListener / DOMContentLoaded code (which monitors the loading of *all* pages), as well as nsLoginManager's fillDocument(). The password field notification would tell us exactly which pages/forms have potential login fields, so password manager can go to sleep until the notification happens.
[Nit: there's also the edge case of changing an existing <input type=text> to type=password, but that could be dealt with separately in a similar manner.]
Lastly, I suspect we'll be needing this for Electrolysis. Having content in a separate process means that the current scheme would probably result in a lot of IPC traffic for every page load. By making it event driven, password manager wouldn't need to do anything with a content process until it gets a notification that there's a password field.
*** Bug 595992 has been marked as a duplicate of this bug. ***
Recently some web sites have begun using a light box that pops up to log-in. One such example is http://imageshack.us/ If you click on the log-in link at the upper right, FF's User Name / Password does not work in that case.
An issue with the imageshack site is that the generated login form has no form element, just a set of input elements. Currently, I believe, the login manager code uses the first text input of the password input's associated form as the username. What would be the desired behavior here? Should it use the first unassociated text input in the document? That would work for imageshack, but I can't see that being reliable.
Oh, and since there is no form, there is no form submission and therefore no way to know when to save the username and password.
*** Bug 486267 has been marked as a duplicate of this bug. ***
These things are becoming irritatingly popular.
*** Bug 675160 has been marked as a duplicate of this bug. ***
For imageshack i use Greasemonkey addon: https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
With this script: http://userscripts.org/scripts/show/100872
Autofills the popup dialog.Crude workaround but atleast gets rid of the annoyance.
*** This bug has been marked as a duplicate of bug 355063 ***
As of this date, I'm running the current version of Firefox (20.0.1) in XP-MCE SP3. I'm also experiencing this bug at the Hotmail-Outlook.com-Live.com or WHATEVER IT'S CALLED login page. I was able to use a bookmarklet to get Firefox to remember my user name and password for the site, but despite this they are not filled in automatically. I've heard that this is an issue with the site being a secured website (https) and that there's a hack to make it work. I don't like doing that kind of thing and hope that the FF developers can see their way to fixing this bug.