don't look for username fields too far from the password field

NEW
Unassigned

Status

()

P3
normal
10 years ago
4 months ago

People

(Reporter: cj_three, Unassigned)

Tracking

({ue})

1.9.0 Branch
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [passwords:heuristics])

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070400 SUSE/3.0.1-8.1 Firefox/3.0.1

If form include a password field, Firefox 3 always auto fill user name into non-user text field, even field name & id is anything.


Reproducible: Always

Steps to Reproduce:
url: http://mydesktop:8080/myproject/ & http://mydesktop:8080/myproject/createuser.do

1. enable FF3 autocomplete
2. clean remember passwords, or remove "mydesktop" related
3. access http://mydesktop:8080/myproject/
4. input username & password, click logon button, and click "remember" on top of client area.
5. access http://mydesktop:8080/myproject/createuser.do by some hyperlink
7. remove telephone, access http://mydesktop:8080/myproject/createuser.do again

Actual Results:  
6. FF3 automatically fill username into telephone field.
8. FF3 automatically fill username into email field.

Expected Results:  
1. dont auto fill anything if field name dont match collection point
2. or only fill password

HTML code for http://mydesktop:8080/myproject/createuser.do:
	<label for="userName">User Name:</label>
	<input type="text" name="userName" maxlength="40" size="32" value="">
	<label for="emailAddress">Email:</label>
	<input type="text" name="emailAddress" maxlength="64" size="32" value="">
	<label for="telephone">Telephone:</label>
	<input type="text" name="telephone" maxlength="32" size="32" value="">

	<label for="description">Description:</label>
	<textarea name="description" cols="30" rows="3"></textarea>

	<label for="password">Password:</label>
	<input type="password" name="password" maxlength="16" size="16" value="">
	<label for="password">Confirm Password:</label>
    <input type="password" name="password1" maxlength="16" size="16" value="">
(Reporter)

Comment 1

10 years ago
Firefox1.5 & 2 is OK for this problem.
Version: unspecified → 3.0 Branch
I'm only getting time-outs.
(Reporter)

Comment 3

10 years ago
please dont directly access my url, it is located in my private network.
you can build similar env by yourself.
(Reporter)

Comment 4

10 years ago
raise "Importance", because I have to clean telephone text field at every time.
Severity: major → critical
Keywords: ue

Updated

10 years ago
Component: Location Bar and Autocomplete → Form Manager
Product: Firefox → Toolkit
QA Contact: location.bar → form.manager
Version: 3.0 Branch → 1.9.0 Branch

Updated

10 years ago
Component: Form Manager → Password Manager
QA Contact: form.manager → password.manager
The bug here is that we currently just look for the first textfield before a password field, and treat that as a username field. The backtracking from the password field should probably not be open-ended. EG, in this case it should ideally notice the <textarea> and treat the form as not having a username field. In other words, it seems unlikely that a login form would stick a <textarea> between the username and password. I could see there being a checkbox or hidden input there, though, so we might want to try to be clever about this.

OTOH, forms in tables might have odd ordering. Eg, consider a username field in row 1/col 1, and a password field is in row 2/col 1, Columns 2-10 might be stuffed with other form elements, which would appear to be in between the username and password fields (from the form's point of view).
Severity: critical → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: wrong fill user name into outlying field when there is a password field → don't look for username fields too far from the password field

Comment 6

6 years ago
I have the same issue.

I have an account creation form with login field towards for start and password field towards bottom. If I have remembered the username/password in the login form on another page (same host) password is filled-in and username is filled into first text input preceding the password field instead of username field.

In addition password mananger should ask if the password should be remembered for exactly one form or all forms for the site. Having multiple login forms/pages/credentials for different purposes on a same site seems reasonable (customer space, admin space or even a list-server with different passwords for different lists).

e.g.
http://site.example/login.html
  <form action="/login.html">
    <input type="text" name="username">
    <input type="text" name="password">
  </form>
http://site.example/new-account.html
  <form action="/new-account.html">
    <input type="text" name="username">
    ... multiple form fields
    <input type="text" name="phone">
    <select name="...">...</select>
    <input type="password" name="password">
    <input type="password" name="password_repeat">
  </form>
http://site.example/admin/login.html
  <form action="/admin/login.html">
    <input type="text" name="username">
    <input type="password" name="password">
  </form>

If I remember password for /admin/login.html Firefox should not reuse these credentials for auto-filling /login.html (though it should for /admin/login.html?some=arguments) and it should not auto-fill the credentials into /new-account.html either.

Two forms containing password fields should be considered related if:
a) they have same set of visible form-fields (same names and types)
b) they share the same form-action

All visible form-fields should get remembered and auto-filled. If one remembered value cannot be applied (read-only field and differing value, missing select/radio option) that field can either be skipped or whole auto-fill aborted.

For comparison under b) it should be decided if query-string shall be ignored or not. Ignoring it should IMHO be sufficient.
Priority: -- → P3
Whiteboard: [passwords:heuristics]
You need to log in before you can comment on or make changes to this bug.