1652715 - [V2 Doorhanger] Other <input> field values are captured as suggested in the username dropdown only after edits of the <username> or <password> fields that are shown in the doorhanger

Status: VERIFIED FIXED

(Toolkit :: Password Manager, defect, P2)

Description

[Timea Cernea [:tbabos][inactive]]

Attachment: Recording of the issue

Affected versions
Nightly 80 - since V2 doorhanger functionality landed with Bug 1641415

Tested on
Windows 10 x64

Steps to reproduce

• Launch Firefox
• Go to Wikipedia Create Account page
• Fill in all the required fields
• Click on the grey key icon and check the suggestions for the username
  observe issue: email should be offered as a suggestion
• Edit the email or New Password field and click on the grey icon to check the username suggestion again
  observe issue: the email is still not added as a suggested username in the dropdown list
• Edit the Username or the CONFIRM password field and check again the suggestions from the doorhanger
  observe that: the email is now added in the dropdown for the username as a suggestion

Expected result
All the intended fields values should be correctly captured and offered as a suggestion for the username in the save doorhanger

Actual Result
The e-mail will be displayed as a suggestion only after editing the username or confirm password field

Regression-range
Not a regression as it can be reproduced in the very first day when Bug 1641415 enabled this new functionality.

Notes
Observed it so far only on wikipedia. Facebook and Instagram are not affected. This could turn into a global issue if we can find it on other sites as well.

Comment 1

[Timea Cernea [:tbabos][inactive]]

This seems to be global after all, the simple rule to follow (on other sites, Wikipedia has steps as stated above) is to always fill in the password field first and then all the other fields.
The other captured username suggestions will be added in the list only after updating the password field or the "username" field that has its value displayed in the doorhanger. Added screen recording for a better understanding.

Comment 2

[Timea Cernea [:tbabos][inactive]]

Attachment: Recording of the issue

Comment 3

[:severin Rudie]

Looks like we're storing all fields as expected as they're modified, but those values aren't being sent to the prompter until either a form is submitted or a password field is modified. I'm working on a fix.

Comment 4

[:severin Rudie]

Attachment: Bug 1652715 - fix pmgr doorhanger only updating on password change & submit;r=MattN

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5acd57b4187d
fix pmgr doorhanger only updating on password change & submit;r=MattN

Comment 6

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/5acd57b4187d

Comment 7

[Timea Cernea [:tbabos][inactive]]

Verified-fixed on latest 80.0a1 (2020-07-24) (64-bit) on WIndows 10, MacOS 10.13 and Ubuntu 16.04.
All the expected <input> fields are captured now even if they were filled after the password field.

There is only 1 edge case I found today that might also be related to how Bug 1612258 should affect register forms.
On the register forms, if we edit one of the username/email/FirstName/LastName fields (after we already filled in the password) and without focusing out of the field we toggle the dismiss doorhanger, the field for the username will remain blank, there was nothing captured.

Toggling the dismissed doorhanger again will show it correctly. So for the register forms, the dismissed doorhanger is not adjusted based on the input events of the candidate username fields. Not sure if Bug 1612258 was meant to handle this case too or it is addressed only to the Login forms where we have strictly 1 username field.
@Bianca, please take a look at this when you have the time.

Attached a screen recording in case I was not clear enough about this.

Comment 8

[Timea Cernea [:tbabos][inactive]]

Attachment: Recording for edge case

Comment 9

[:severin Rudie]

Although very similar from a user perspective, this takes a different code path than bug 1612258. I'll file a bug for the edge case and assign myself.