Open Bug 1517971 Opened 6 years ago Updated 2 years ago

Look for the appropriate username in text nodes when deciding which saved login to fill

Categories

(Toolkit :: Password Manager, defect, P3)

Product:
Toolkit
Component:
Password Manager
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: danweiss, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 obsolete files) 

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Some websites will remember your username, then ask you for your password again.  This badly breaks the password manager feature, as it cannot pick a username to associate with a password.

For example, a website may display a remembered username in a text element located above the Password box.

So we need a way for Firefox to pick a remembered username if there is a text element near the password box that contains that username.

Websites can use hidden <input> if they want to play nice with password managers. Adding this to the backlog.

Priority: -- → P3
Summary: Password manager fails on websites which display a remembered username as a text element instead of a form field → Look for the appropriate username in text nodes when deciding which saved login to fill
Blocks: 1583576

Are we actually contemplating implementing this? Trawling through nearby elements looking for a username without any formal or informal semantics to narrow that search doesnt sound like it would yield high signal to noise ratio.

I know Chrome does this at least for address/credit card autofill so that's one data point. They have like 9 different ways to identify a field type and they even go as far as to look in adjacent table cells.

The username searching heuristic locates a username like or an email like field
by:

  1. Checking if the input field's type is 'email'.
  2. Checking if the input field's autocomplete attribute is 'username' or 'email'
  3. Searching 'username' and 'email' keyword in:
    • The input field's "id", "name", "classname", and "placeholder" attributes.
    • The input field's associate label

If any of the above rule matches, we consider the field a username or an
email field depending on the keyword that matches.

When both a username-like and an email-like field are found in a form, select
the username-like field as the final username field. If no field is
found by the above heuristic, assume the first field before the first
password is the username (This is how it works before the patch).

Note. Right now, even with the new heuristic, we still only search fields
preecede the first password field like what we did before. This is because
from the sites I have tested (~250 sites), all the username fields
precede the first password field. If it turns out this is not true for
some sites, we can consider searching all the input fields in the form.

Assignee: nobody → dlee

Dimi, this bug isn’t about searching <input>, it’s about searching text nodes. Are you planning to add more commits to address that? Otherwise it seems like this is the wrong bug. I’m curious to know what you’re actually trying to solve.

Flags: needinfo?(dlee)

Comment on attachment 9212926 [details]
Bug 1517971 - P1. Implement a heuristic to locate the username field in a form. r=sfoster

Revision D110469 was moved to bug 1690865. Setting attachment 9212926 [details] to obsolete.

Attachment #9212926 - Attachment is obsolete: true

Comment on attachment 9212927 [details]
Bug 1517971 - P2. Add testcases for the username searching heuristic r=sfoster

Revision D110470 was moved to bug 1690865. Setting attachment 9212927 [details] to obsolete.

Attachment #9212927 - Attachment is obsolete: true

Comment on attachment 9212930 [details]
WIP: Bug 1517971 - P3. Add tests to test isInferredUsername and isInferredEmail

Revision D110471 was moved to bug 1690865. Setting attachment 9212930 [details] to obsolete.

Attachment #9212930 - Attachment is obsolete: true

Hi Matt,
Really appreciate you pointing out my mistake, thanks! You are right, I've field bug 1690865 to implement the username detection heuristic but I submitted my patch to the wrong bug. I just updated it.

The problem I am trying to solve is that when we don’t detect the correct username field, the doorhanger doesn’t use the right username by default. We do allow the user to select the right username by the dropdown, but I think making the default one correct is important.

These mostly happen in sign-up pages. I tested with 250 fathom samples, around 10% sites having this issue. For sign-in pages, the current heuristic works fine in most of the cases, but there are still a few cases. Another issue is that if users already have logins saved for the domain, the autocomplete dropdown is shown in the wrong field (but maybe a better solution is not autofill/autocomplete at all for sign-up page?). But the main purpose here is to select the right username by default.
Please let me know if you have any suggestions, It would be great to hear any feedback from you!

Flags: needinfo?(dlee)
Assignee: dlee → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: