Update doorhanger might be displayed 2 times due to site fast reload/redirect and instant auto-fill
Categories
(Toolkit :: Password Manager, defect, P3)
Tracking
()
People
(Reporter: tbabos, Unassigned)
References
Details
(Whiteboard: [passwords:capture-UI])
Attachments
(2 files)
Affected versions
Nightly71
Beta70
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.
Notes
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 reddit.com
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
Comment 2•5 years ago
|
||
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.
Comment 3•5 years ago
|
||
For twitter.com/login, 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.
Comment 4•5 years ago
|
||
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
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 5•3 years ago
|
||
Moving to P3 as this is not happening in the next release cycle.
Updated•2 years ago
|
Description
•