User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Firefox is populating fields with remembered account information when it shouldn't be. It appears that Firefox is using some sort of pattern matching to determine if fields should be populated with account information. Example: The login page has one <input type="text" . . /> element that represents the login id, followed by a <input type="password" . . /> element that represents a password field. Upon completing this form and selecting the Remember Me option the user visits another page, let's say an account creation page or a checkout page. Firefox detects a password field on the page and populates the password field with the stored password. Firefox then proceeds to populate the previous field with the login id, regardless if that field is meant to be used as a login field. Reproducible: Always Steps to Reproduce: 1. Create a simple HTML file that has a form that represents a login form 2. Complete the form with valid login information. 3. Select the remember me option when prompted. 4. Create another simple HTML file that has a form that represents a registration page. This form should contain multiple <input type="text". . /> elements with a <input type="password" . . /> element thrown in somewhere on the page. 5. Load this page with Firefox, and view results. Actual Results: You should now see the stored login id and password appear on the form. You should be able to move the <input type="password" . . . /> around on the form and see that Firefox populates any <input type="text" . . /> above the password text box on the form. Expected Results: I would have expected Firefox to only populate a fields that match the name HTML attribute on the form fields, rather than using some sort of pattern matching to accomplish this. I have some very basic HTML files that I created to reproduce this issue. I can send them to the team that will be correcting this issue if needed. I'm not sure if this is expected behavior or is a bug. I'm looking for a statement that this will be fixed at some point or this is working as expected.

Here are some simple test cases that I wrote. Use login.html then take a look at test1.html and test2.html to see my issue.

This bug is (still?) present in Firefox 28 ( "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0" ). I could confirm it with the HTML test case and a tool I work with daily.

I suspect we would break a bunch of sites if we only filled in to a username field with the same id/name. We are saving this data it seems but I don't think we're using it for this purpose. I think there are many sites which use a different username id/name on their registration and login forms but I don't have data on that.

I wonder about "breaking" sites. A programmer doesn't choose different IDs/names for input fields just because he can, but because thee fields represent different things or he intentionally wants to prevent auto-filling. At least that's what I think. And in that case, Firefox' behavior does not honor the intent of the programmer, i.e. it's already "breaking" the site. Does anyone know how other browsers handle this case?

I think we should use the usernameField value to help our heuristic choose the best username field (if there is a match) but I don't think we'll require an exact match for form fill as there are enough sites that don't use the same usernameField identifier. We can do the same with the password field too. Note that we are review how we handle registration, login and reset forms in the following bugs so there may be other fixes which improve comment 0 behaviour: 1119507, 1119514, 1119554

It could be useful as a heuristic, but these fields change over time and across pages. Which means either dealing with updates (and then breaking the heuristic on other pages where the field name differs, or storing multiple field names), or leaving the names static (like today) and they become increasingly less useful to the heuristic due to site changes. I'd make this a very low priority, probably even just WONTFIX.