Open Bug 1325437 Opened 3 years ago Updated 9 months ago

Don't automatically show autocomplete UI upon focusing a non-empty username field

Categories

(Toolkit :: Password Manager, defect, P3)

52 Branch
defect

Tracking

()

Tracking Status
firefox50 --- unaffected
firefox51 --- unaffected
firefox52 --- fix-optional
firefox53 --- affected

People

(Reporter: MattN, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [passwords:fill-ui])

+++ This bug was initially created as a clone of Bug #1318203 +++

When a username field is focused then marked as a login manager field or marked as a login manager field and then focused, we shouldn't automatically open the autocomplete popup as it doesn't add any value if the username is already correct. If it's not correct, the popup will automatically open as the user starts typing.
Matt, are you saying ath if the username field is pre-populated by a website, we shouldn't show the autocomplete UI?  I'm a bit confused.
Yeah, that's what I was thinking for now but I keep flip-flopping on whether to take the password field contents into account.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #0)
> When a username field is focused then marked as a login manager field or
> marked as a login manager field and then focused, we shouldn't automatically
> open the autocomplete popup as it doesn't add any value if the username is
> already correct.

It can add value if the password field isn't filled because it allows the user to fill in the password as well. If the password field is already filled with a matching[1] password then we're showing UI for no reason.

[1] We need to ensure if we take matching into account that we don't introduce ways for a user to brute force a saved password without entering the MP. That seems unlikely though since the username is already encrypted by MP and the username is required for the autocomplete results.

Here are some cases to consider:
A) If Fx autofills the username and password on a secure form because we have one matching login, the site may still focus the username field because they are assuming the user needs to type their username and password. Upon focus we open the useless autocomplete popup since the password is already filled.
B) If the site remembers the users' username in a cookie or local storage and pre-fills the username field with the remembered value, and then focuses the username field anyways. I don't know how common this case is as they probably should focus the password field if they pre-fill the username field.

If we only want to not auto-show the popup after we auto-filled then bug 1294194 is about remembering when+what we autofill.
I'm not sure what the right UX is here.  And there are many options to consider:

1) If the username field is prepoluated by the website and the user has 1 stored login for the site that matches that username.

2) If the username field is prepoluated by the website and the user has 1 stored login for the site that doesn't match that username.

3) If the username field is prepopulated by the website and the user has more than one stored login for that site.

And then we have password combinations.
AND

A) The password is not prefilled.
B) The password is prefilled with a value that matches what Firefox has stored
C) The password is prefilled with a value that doesn't match what Firefox has stored.


I'm not too worried about attempts to brute force passwords without access to Master Password.
Flags: needinfo?(rfeeley)
We should not automatically show the autocomplete UI when the page focuse a non-empty username field, but we can when the user does. Otherwise the user can start press down arrow, double click, or start typing part of the username to bring up the list.
Flags: needinfo?(rfeeley)
As an operating principle, user testing proves that Firefox users appreciate the convenience of logins being filled in automatically. Our "happy path" is to fill the username and password field when it's safe to do so. There are of course many sad paths, we can deal with, but please remember that this feature is more about convenience than control.

(In reply to Tanvi Vyas - behind on bugmail [:tanvi] from comment #3)
> 
> 1) If the username field is prepoluated by the website and the user has 1
> stored login for the site that matches that username.

We should fill the password in if the username was the same. Should be seamless for the user.

> 2) If the username field is prepoluated by the website and the user has 1
> stored login for the site that doesn't match that username.

When the user deletes the content of the username field, we can suggest others. We should not fire up any UI until that happens.

> 3) If the username field is prepopulated by the website and the user has
> more than one stored login for that site.

When the user delete the content from the field, we can suggest the others.

> And then we have password combinations.
> AND
> 
> A) The password is not prefilled.
> B) The password is prefilled with a value that matches what Firefox has
> stored
> C) The password is prefilled with a value that doesn't match what Firefox
> has stored.

I assume the password field is never prefilled by the website.
We should never fire the dropdown menu on a password field if a username field is present/detected on the page.
We should not fire the dropdown on the password field unless the password field is empty.
Blocks: 1335332
Whiteboard: [passwords:fill-ui]
Priority: -- → P3

We don't auto-show on the username field if the username field was already filled since bug 1330111. I'm not sure if there is more to do here for the username field popup. It would be good to know if people are seeing the popup on the username field when we obviously shouldn't show it.

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