Open Bug 1583150 Opened 5 years ago Updated 1 year ago

Update doorhanger might be displayed 2 times due to site fast reload/redirect and instant auto-fill


(Toolkit :: Password Manager, defect, P3)




Tracking Status
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix


(Reporter: tbabos, Unassigned)



(Whiteboard: [passwords:capture-UI])


(2 files)

Attached file Colnsole Log

Affected versions
Release 69

Affected platforms
Windows 10 x64

Steps to reproduce

  • Launch Firefox
  • Go twitter or facebook log in page
  • Save a set of credentials
  • Refresh the log in page to toggle autofill
  • Replace the pre-filled password with a new one
  • Click on Log in
  • Quickly confirm the update in the doorhanger

Expected result
After confirming the update, the new password should be saved and auto-filled in the field after the page has refreshed itself (works best with incorrect passw page error)

Actual Result
The update doorhanger is displayed twice:

  • once after clicking on Log in -> prompts to update with the new password - this is fine
  • the second time after the page refreshed/redirect itself -> due to the quick refresh and auto-fill, the field will be populated again with the old password (not the new one) and will offer the user to update again the password with the old one.

My guess is that the page auto-fill does not wait and request the new password value and proceeds to instantly complete it with the old one upon automatic page refresh or redirect.
Given its a new password (not the one updated before) the doorhanger appears once more and updates back to the previous password. Check attached log and recording

Not reproducible on

I can reproduce this (intermittently) and it appears it is not fixed by 1576199 (and is not a regression caused by it)
So far, I can see that the lookup in LoginManagerContent.jsm that should detect that we already prompted for this change is not working for this case; the state is lost and we reset and message the parent to prompt again.

Assignee: nobody → sfoster

For, there are 3 forms that submit when you hit "login". The main response has more forms on it, that are populated with username/password values - a couple with the original password, one with the new value - and automatically submitted again. For this one interaction we see 10 calls to _onFormSubmit, with 5 different form/formLikeRoot elements. As our caching uses this element as the key for the previously-sent values, we get a lot of cache misses. There's more detail, but I think the short story is that while we can eliminate some redundant messages to the parent process, to meet the goal of overlapping/redundant doorhangers, we'll need to have some logic in the parent process too.

Not a P1, afaict this is not a regression. I'm not sure yet what the right approach is here, but it may not be a quick fix we can expect to land ahead of other priorities

Priority: -- → P2
Depends on: 1388674
See Also: → 1600397
Whiteboard: [passwords:capture-UI]
Assignee: sfoster → nobody

Moving to P3 as this is not happening in the next release cycle.

Priority: P2 → P3
Depends on: 1771806
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.