Open Bug 1690996 Opened 3 years ago Updated 3 years ago

[Dismissed Doorhanger] Grey key is displayed upon switching between saved credentials via the autocomplete dropdown

Categories

(Toolkit :: Password Manager, defect, P2)

80 Branch
Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr78 --- unaffected
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- fix-optional

People

(Reporter: tbabos, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Attached video Recording of the issue

Affected Versions:

  • Nigthly 87.0a1 (2021-02-04)
  • Beta 86.0b5
  • Release 85.0

Tested On:

  • MacOS 10.15
  • Windows 10 x64

Steps to reproduce:

  1. Have 2 set of credentials saved for any site, ex: facebook
  2. Reach the login form
  3. Select the first saved credentials from the username/email autocomplete dropdown
  4. Clear the filled in username field
  5. Select the second saved credential from the username/email autocomplete dropdown

Expected Result:
Given the password was also autofilled again to match the selected username, there should be no dismissed doorhanger displayed.

Actual Result:
Grey key icon is displayed, opening the doorhanger will ask the user if the credentials should be updated.

Notes:

  • Regression of Bug 1612258 (bisected manually for "first release with/without") - the second autofill toggled by switching to a different set of credentials is registered as input event, thus toggling the dismissed doorhanger.
  • Save doorhanger on form submit is not affected (not displayed on form submit)
  • Severity: Fortunately, even if the user selects to update the credentials from the doorhanger it won't cause any credential loss since we are already adjusting capture based on input events so we end up updating the same info for the filled-in credentials - S3.

Debug Log:
Login storage: _searchLogins: returning 2 logins for
Object { formActionOrigin: "https://www.facebook.com", origin: "https://www.facebook.com" }
with options
Object { acceptDifferentSubdomains: undefined, schemeUpgrades: true }
storage-json.js:569:10
LoginManagerParent: _onPasswordEditedOrGenerated: not auto-saving this login LoginManagerParent.jsm:1186:10
LoginManagerParent: _onPasswordEditedOrGenerated: No change to existing login LoginManagerParent.jsm:1236:12
LoginManagerParent: _onPasswordEditedOrGenerated: Has doorhanger? true LoginManagerParent.jsm:1240:12
LoginManagerPrompter: _showLoginCaptureDoorhanger, got autoSavedLoginGuid: LoginManagerPrompter.jsm:171:9
LoginManagerPrompter: _showLoginCaptureDoorhanger, got autoFilledLoginGuid: {d277f1e1-8ff4-4f48-837a-0ba9f84c7376} LoginManagerPrompter.jsm:174:9
LoginManagerPrompter: removed

The unaffected build does this check shown in the console:
LoginManagerChild: _formHasModifiedFields, userHasInteracted: true LoginManagerChild.jsm:2450:8
LoginManagerChild: _compareAndUpdatePreviouslySentValues: values are equivalent, returning true LoginManagerChild.jsm:509:12
LoginManagerChild: (field edit ignored -- already submitted with the same username and password) LoginManagerChild.jsm:1718:12

Further testing on different sites revelead that this happens only when switching between accounts that have different passwords.
Switching between the accounts with the same password will not toggle the dismissed doorhanger, so there is definitely a check done on the password field for change events.
Unfortunately seems like it does not also check the username field change event as well and offers to update instead of acknowledging that the credentials were switched from the username field.

Priority: -- → P2
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: