1663039 - With Autofill disabled, password is automatically filled after manually entering a saved username and blurring the username field

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect, P3)

Description

[Emily Kager [:ekager]]

From github: https://github.com/mozilla-mobile/fenix/issues/14686.

Steps to reproduce

1. Save a few passwords for a website.
2. Go to Settings>Logins> turn off Autofill
3. Return to the website and tap the username field.
4. Fill in the username and tap the "next" button from the keyboard to jump to the password field.

Expected behavior

The suggested logins list shouldn't appear(?) - not sure about the desired behavior.
The password field shouldn't be auto-filled.

Actual behavior

When you jump from the username to the password field using the keyboard, the password is auto-filled.
The suggested logins is still displayed.

Device information

• Android device: Nexus 5 (Android 5)
• Fenix version: 81.1.0-beta.2

Comment 1

[Emily Kager [:ekager]]

Eugen, I'm setting the loginAutofillEnabled setting here so I'm assuming this would be a GV bug but if you think Fenix is doing something wrong I can move it back.

Comment 2

[Eugen Sawin [:esawin]]

This is likely a Fenix issue, it looks like expected behavior from the GV API. Let's evaluate it step-by-step:

1. Save a few passwords for a website.
   Assuming this means login entries (un/pw pairs) and few means > 1, this step renders the loginAutofillEnabled setting irrelevant.
   Autofill occurs only in the case where there is exactly one valid un/pw pair returned by onLoginFetch.
2. Go to Settings > Logins > Turn off Autofill.
   This sets loginAutofillEnabled to false.
3. Return to the website and tap the username field.
   With loginAutofillEnabled set to true and assuming only one login entry returned by onLoginFetch, tapping the un field is not required for autofill, the fields would be automatically filled on page load.
   With loginAutofillEnabled set to false this behavior is blocked.
   By tapping into the un field, we're triggering autocomplete behavior with the expected onLoginSelect request.
   This request is likely never dismissed or confirmed, given the next steps.
4. Fill in the un and tap the next button.
   Focusing on the pw field would trigger onLoginSelect with a generated password.
   Assuming the request from step 3 is still pending, the request for the generated password is dismissed by GV.
   This is the behavior I am reproducing, the reporter seems to see different behavior in this step, this might need further discussion.

Comment 3

[Emily Kager [:ekager]]

Attachment: ezgif.com-video-to-gif(1).gif

Hey sorry for the delay. So I'm a bit confused about 3+4. Is it expected behavior that with autofill off when a matching email is filled then the password will also be filled? I'm not seeing a "generated password" (I'm understanding this to mean a new password) I'm seeing the matching password. Attached a gif of the behavior I'm seeing with a fake LinkedIn login.

Comment 4

[Eugen Sawin [:esawin]]

(In reply to Emily Kager [:ekager] from comment #3)

Created attachment 9175678 [details]
ezgif.com-video-to-gif(1).gif

Hey sorry for the delay. So I'm a bit confused about 3+4. Is it expected behavior that with autofill off when a matching email is filled then the password will also be filled? I'm not seeing a "generated password" (I'm understanding this to mean a new password) I'm seeing the matching password. Attached a gif of the behavior I'm seeing with a fake LinkedIn login.

Thanks for the gif. You are right that in the case of a matching username the password will be filled despite the autofill setting.
This seems to be expected behavior on desktop, because it's strictly speaking not autofill since it involves user interaction.

However, this is not acceptable behavior for the GV API, given that there is no way to prevent the filling of the password in this case.
Let us explore a change in behavior in Gecko.

One simple solution would be to take the autofill pref (signon.autofillForms) into account when filling a password in the case of a (auto-) filled username.
Would this be an acceptable solution for desktop (I'm going to attach a patch for review), Bianca?

Comment 5

[Eugen Sawin [:esawin]]

Attachment: Bug 1663039 - [1.1] Don't autofill passwords for exact username matches when autofilling is disabled.

Comment 6

[Bianca Danforth [:bdanforth]]

This seems to be expected behavior on desktop, because it's strictly speaking not autofill since it involves user interaction.

In general, yes this is expected behavior. Autofill as we define it for the Firefox Password Manager refers to the behavior of filling in logins without user interaction, so technically speaking, this is not Autofill. The confusion of course is that we are "automatically filling" the password after the user has entered a username value that uniquely matches a saved login and blurred the field.

From a privacy/security perspective (see Bug 1118511), the user has signaled their intent to login using this form by filling in a saved login's username, so I don't think it's a bad assumption to make that they intend to enter their password after blurring the field, but whether or not we fill it on their behalf as their user agent and whether that violates their expectations when Autofill is disabled is a UX grey area.

KatieC, what are your thoughts?

Comment 7

[Bianca Danforth [:bdanforth]]

Upon thinking about this more, and talking with other engineers on the Password Manager team, I agree that we probably want to change the behavior here. I'll move this over to the Password Manager component for now, so it gets triaged.

Eugen, thanks for your patch. I'm working on a related bug that is higher priority than this, but I will swing back around hopefully early next week to look at your fix. If I can't get to it by then, I'll ask sfoster to take a look.

KatieC, clearing your NI, as I feel more certain about it now, but let us know if you're thinking differently here.

Comment 8

[Eugen Sawin [:esawin]]

Attachment: Bug 1663039 - [2.0] Add GV test to verify autofillEnabled setting is respected.

Depends on D90421

Comment 9

[Eugen Sawin [:esawin]]

Attachment: Bug 1663039 - [3.1] Add mochitest for changed password autofill behavior.

Depends on D92245

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d00b8f2e97bb
[1.1] Don't autofill passwords for exact username matches when autofilling is disabled. r=sfoster
https://hg.mozilla.org/integration/autoland/rev/d12faea488c4
[2.0] Add GV test to verify autofillEnabled setting is respected. r=geckoview-reviewers,agi
https://hg.mozilla.org/integration/autoland/rev/0e1fd2feadaf
[3.1] Add mochitest for changed password autofill behavior. r=sfoster

Comment 11

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/d00b8f2e97bb
https://hg.mozilla.org/mozilla-central/rev/d12faea488c4
https://hg.mozilla.org/mozilla-central/rev/0e1fd2feadaf

Comment 12

[Laurentiu Apahidean]

Verified as fixed on Firefox Preview Nightly 201025 (Build #2015771787) using a OnePlus 6T (Android 9) and Samsung Galaxy S9 (Android 8.0.0).