Craig Francis Reporter
	Description • 11 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

Add a "saved password" for the website:

http://www.thriveapproach.co.uk/

For example, one for an admin account, then load the member register page:

http://www.thriveapproach.co.uk/member/register/


Actual results:

The postcode field (one back from the new password field) is assumed to be the username for the saved password.


Expected results:

Please see the HTML5 spec for the new autocomplete attribute:

http://www.w3.org/TR/html5/forms.html#autofilling-form-controls:-the-autocomplete-attribute

Ideally it the password manager would see this as being an inappropriate field for the username.

	Loic
	Comment 1 • 11 years ago

Do I need to create a fake account to test?

	Craig Francis Reporter
	Comment 2 • 11 years ago

I don't think so... I just don't know the FireFox password manager well enough to manually enter a username/password for a domain.

As in, getting a record to appear in "Preferences > Security > Saved Passwords".

	Loic
	Comment 3 • 11 years ago

Could you add clear STR to reproduce the bug, step by step, please.

	Craig Francis Reporter
	Comment 4 • 11 years ago

1) Use a fictional username/password on this dummy page:

http://www.thriveapproach.co.uk/test/

2) When you submit the form, use the password manager (little key in address bar if hidden) to "Remember password".

3) Now view the register page:

http://www.thriveapproach.co.uk/member/register/

The form should be blank, but the password manager has tried to fill out the postcode field with the username entered above.

	Loic
	Comment 5 • 11 years ago

It's clear now. :)
Same issue in old versions too.

	Matthew N. [:MattN]
	Comment 6 • 10 years ago

I can reproduce this (although there is now a maxlength=8 on the postcode field so you need to test with a username <= 8 characters).

	Edwin Wong [:edwong]
	Comment 7 • 9 years ago

Setting as P3 - is this something we want to fix this qtr?

	Dan
	Comment 9 • 9 years ago

Seen the same problem of username being placed in fields that have nothing to do with logging in.

For example, on a form for editing user details:

<form>
<input type='text' name='username'>
<input type='text' name='firstname'>
<input type='text' name='lastname'>
<input type='password' name='pw' autocomplete='off'>
</form>

The "lastname" gets filled with my login username, and the "pw" field gets filled with my password.  I realize the second is a result of more herculean efforts by Mozilla to make sure password fields can be filled in even when autocomplete is disabled, but putting my username into the "lastname" field is a bit much.

The password manager is trying too hard to fill in forms to the point that it fills out forms that aren't even login forms.  Restricting the saved password to those with the same ACTION would not prevent saved psswords from working, but it would fix the issue I describe.  It might lead to having to save your password multiple times on a site that used login forms with different ACTIONs, but that seems like an acceptable compromise.

This behavior has recently gotten much worse, and I'm not sure if I just noticed, or it was a result of https://bugzilla.mozilla.org/show_bug.cgi?id=956906

	vinnyjames
	Comment 10 • 9 years ago

This is a problem on all sites where you can edit your username/password and all sites where you can edit other users' credentials.  It appears the problem spawns from banks and the like that try to disable this on forms as they see fit instead of allowing the user to make that decision.

The proposed solution does not put the onus on the company that is misusing autocomplete but rather the random innocents like admins and developers who have access to many forms with username+passwords that are not their logins.

It would be more just to notify end-users that a site is trying to prevent them from saving their credentials and allowing them to override it.  This puts the blemish where it belongs instead of inconveniencing the rest of the world.

	Dan
	Comment 11 • 9 years ago

I agree with the idea of giving the user the option of overriding the behavior of autocomplete.  This however, does not solve the problem where the user has elected to save the password for a site, but then uses another form where password (and username) should not be autofilled.

Since it is often site admins that need this functionality, perhaps an option could be included to prevent it from applying to certain actions, rather than trying to restrict it to the original action of the login form (which could change for websites and annoy end users).

I think my preferred solution is to popup a box that asks if you want to autofill this form with your password when a new form with a new action is loaded.  The user can simply click "yes" and have this form added to their list of forms that are ok to autofill (the original having been automatically added when Fx asked if they wanted to save the password).  As a backwards compatibility measure, those saved passwords that had no action saved along with them could apply to all forms on a site until the user manually updates them.

	Matthew N. [:MattN]
	Comment 12 • 9 years ago

(In reply to Dan from comment #9)
> <form>
> <input type='text' name='username'>
> <input type='text' name='firstname'>
> <input type='text' name='lastname'>
> <input type='password' name='pw' autocomplete='off'>
> </form>
> 
> The "lastname" gets filled with my login username, and the "pw" field gets
> filled with my password.  

This bug is about autocomplete attributes with values other than on/off e.g. autocomplete="family-name" / autocomplete="new-password" and since you're not using those this bug won't help you. You can add them to get the benefits when we fix this bug (which I hope to fix this year) but in the meantime I recommend reordering the fields so the username field is before the password field as that will help in the edit case since we will see a different username and not try to fill the user's password there.

(In reply to vinnyjames from comment #10)
Please use autocomplete="new-password" on fields where an admin is setting a new password for a user in order to get the benefit when this bug is fixed.

(In reply to Dan from comment #11)
> Since it is often site admins that need this functionality, perhaps an
> option could be included to prevent it from applying to certain actions,
> rather than trying to restrict it to the original action of the login form
> (which could change for websites and annoy end users).

This option already exists: You can flip the pref signon.autofillForms in about:config to false to disable autofill.

	vinnyjames
	Comment 13 • 9 years ago

Thanks for the clarification Matthew

	Dan
	Comment 14 • 9 years ago

(In reply to Matthew N. [:MattN] from comment #12)
> This bug is about autocomplete attributes with values other than on/off e.g.
> autocomplete="family-name" / autocomplete="new-password" and since you're
> not using those this bug won't help you. You can add them to get the
> benefits when we fix this bug (which I hope to fix this year) but in the
> meantime I recommend reordering the fields so the username field is before
> the password field as that will help in the edit case since we will see a
> different username and not try to fill the user's password there.

Well, I posted here for lack of a better bug to discuss this issue.  But, I can create a new bug if that's preferred.  Your idea would help a bit, but it doesn't help for new users.

> 
> (In reply to vinnyjames from comment #10)
> Please use autocomplete="new-password" on fields where an admin is setting a
> new password for a user in order to get the benefit when this bug is fixed.
 
How long before banks start using that to prevent us from saving passwords again?  It seems to me that autocomplete/autofill are two different things.  Why mess with autocomplete keyword further in this way?

> (In reply to Dan from comment #11)
> > Since it is often site admins that need this functionality, perhaps an
> > option could be included to prevent it from applying to certain actions,
> > rather than trying to restrict it to the original action of the login form
> > (which could change for websites and annoy end users).
> 
> This option already exists: You can flip the pref signon.autofillForms in
> about:config to false to disable autofill.

I think you must have misunderstood me.  Turning it off for the whole browser is not the same as restricting it to certain "actions" (by which I mean the "action" attribute of the "form" element) on a certain site.  The idea was that if there were two forms:

<form action="/login" />
<form action="/createuser" />

you could right click in the field/form somewhere, and indicate that for the "/createuser" action, autofill was not to occur (leaving it to occur on the "/login" action).  In this way, forms that annoyingly have the wrong data filled could be blacklisted.

However, I like my other idea better, that of asking users if they want to fill a form that has a different "action" attribute than the one that was saved.

	vinnyjames
	Comment 15 • 9 years ago

(In reply to Dan from comment #14)
> How long before banks start using that to prevent us from saving passwords
> again?  It seems to me that autocomplete/autofill are two different things. 
> Why mess with autocomplete keyword further in this way?

Is this chronology correct?

1. websites like banks disable autofill with autocomplete (not sure why we're picking on banks but seems like the most plausible culprit)
2. users grab pitchforks and demand autocomplete is no longer honored by the browsers to disable autofill
3. new feature to identify fields as specific types of fields gives websites the exact functionality they misused previously

Naturally I prefer my solution of putting the egg on the appropriate site's face and not in the laps of the masses.

	Dan
	Comment 16 • 9 years ago

(In reply to vinnyjames from comment #15)
> (In reply to Dan from comment #14)
> > How long before banks start using that to prevent us from saving passwords
> > again?  It seems to me that autocomplete/autofill are two different things. 
> > Why mess with autocomplete keyword further in this way?
> 
> Is this chronology correct?
> 
> 1. websites like banks disable autofill with autocomplete (not sure why
> we're picking on banks but seems like the most plausible culprit)
> 2. users grab pitchforks and demand autocomplete is no longer honored by the
> browsers to disable autofill
> 3. new feature to identify fields as specific types of fields gives websites
> the exact functionality they misused previously
> 
> Naturally I prefer my solution of putting the egg on the appropriate site's
> face and not in the laps of the masses.

Sounds about right. See bug: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

From the first post:

> This behavior is a concession to sites that think password managers are harmful and thus want to 
> prevent them from being effective. In aggregate, I think those sites are generally wrong, and 
> shouldn't have that much control over our behavior.
> I think we should investigate removing support for autocomplete="off" entirely, or at least the 
> portion of it that prevents us from saving passwords.

Then, see https://bugzilla.mozilla.org/show_bug.cgi?id=1119063

First post:

> A risk is that it will be used to prevent autofill on login forms i.e. a new way to do 
> @autocomplete=off that goes against the user's control

Perhaps we should take our crusade over there.  :)  However, that bug is specifically for adding the "new-password" option, so I don't see it as the right place to discuss the bad autofill behavior.

	Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo
	Comment 17 • 9 years ago

@Dan and @Vinnyjames: the discussion on this bug tailed of six months back. Do you have a way to move this forward, or should I moved this out of ASSIGNED and unassign it from @MattN?

	Matthew N. [:MattN]
	Comment 18 • 9 years ago

This is just blocked on the dependency (bug 1109188)

	:Gijs (he/him)
	Comment 20 • 6 years ago

Matt, looks like the dep for this got fixed (the dupe of the bug in comment #18, that is). What's the current status?

	Pulsebot
	Comment 24 • 5 years ago

Pushed by sfoster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/64e2378a756b
Consider autocomplete fieldname when determining what is a username field. r=MattN

	Pulsebot
	Comment 27 • 5 years ago

Pushed by sfoster@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/004ff60a5824
Consider autocomplete fieldname when determining what is a username field. r=MattN