Last Comment Bug 518516 - Make login manager work with JS generated forms (after pageload)
: Make login manager work with JS generated forms (after pageload)
Status: RESOLVED DUPLICATE of bug 355063
:
Product: Toolkit
Classification: Components
Component: Password Manager (show other bugs)
: Trunk
: All All
: -- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://digg.com
: 486267 595992 675160 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-23 23:09 PDT by Justin Dolske [:Dolske]
Modified: 2013-04-30 08:24 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Justin Dolske [:Dolske] 2009-09-23 23:09:28 PDT
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.
Comment 1 Justin Dolske [:Dolske] 2010-01-06 23:56:46 PST
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.
Comment 2 Justin Dolske [:Dolske] 2010-09-22 14:41:17 PDT
*** Bug 595992 has been marked as a duplicate of this bug. ***
Comment 3 RobertJ 2010-11-24 13:32:05 PST
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.
Comment 4 Matt Cosentino 2010-11-25 19:44:21 PST
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.
Comment 5 Matt Cosentino 2010-11-25 19:51:19 PST
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.
Comment 6 Tim (fmdeveloper) 2011-02-27 00:04:46 PST
*** Bug 486267 has been marked as a duplicate of this bug. ***
Comment 7 dgrogan(chrome) 2011-03-24 23:47:28 PDT
http://archives.newyorker.com/ is another example.  I believe there is no form element and the input elements are created by javascript after the page loads.
Comment 8 tomorrow 2011-03-25 17:46:28 PDT
https://store.steampowered.com/login/ too.
Comment 9 Gingerbread Man 2011-05-14 02:32:45 PDT
http://www.officeformac.com/ProductForums/

These things are becoming irritatingly popular.
Comment 10 Jonas Nagel 2011-07-29 02:20:38 PDT
*** Bug 675160 has been marked as a duplicate of this bug. ***
Comment 11 Jonas Nagel 2011-07-29 02:23:07 PDT
https://www.vmware.com/accounts/

Same here.
Comment 12 tomorrow 2011-07-29 05:38:53 PDT
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.
Comment 13 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-12-03 11:29:42 PST

*** This bug has been marked as a duplicate of bug 355063 ***
Comment 14 John Corliss 2013-04-30 08:24:27 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.