1653138 - Password Manager code does not run when DOMInputPasswordAdded occurs between DOMContentLoaded and load events

Status: VERIFIED FIXED

(Toolkit :: Password Manager, defect, P2)

Description

[Bianca Danforth [:bdanforth]]

Attachment: no_dismissed_doorhanger_editing_pw_field_VirusTotal.txt

STR:

1. In a clean profile in Firefox 80, go to https://www.virustotal.com/gui/sign-in
2. Enter a single character into the password field

Actual results:
There is no dismissed login capture doorhanger

Expected results:
There is a dismissed login capture doorhanger

Attached are the logs.

Additional notes:

• This page is a Case 1 example for the Meta Bug 1629226 Shadow DOM work; see the Description for that bug for how different Shadow DOM cases are defined.
• Initial debugging indicates that, while the "DOMContentLoaded" listener is added in _processDOMInputPasswordAddedEvent1, it never fires, so the "input" event listeners are never added2 before the password field is edited.
  • Since we don't receive the "input" event in LoginManagerChild.jsm, we never call _passwordEditedOrGenerated, and the dismissed login capture doorhanger does not show.

The question to answer here is: Why doesn't the "DOMContentLoaded" event fire? There are no <iframe>s on the page (based on a search in the Inspector DevTools page).

Comment 1

[Bianca Danforth [:bdanforth]]

Attachment: Bug 1653138 - Arm onDOMInputPasswordAdded DeferredTask when document.readyState is 'interactive'. r=MattN

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/df25a6a17957
Arm onDOMInputPasswordAdded DeferredTask when document.readyState is 'interactive'. r=MattN

Comment 3

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/df25a6a17957

Comment 4

[Timea Cernea [:tbabos][inactive]]

Verified-fixed on latest Beta 80.0b1 on Windows 10 and MacOS 10.13 for https://www.virustotal.com/gui/sign-in

However, also checked it on Wego.com where this specific case of 1 password character is not fully covered.
STR:

1. Load https://www.wego.com/
2. Click on Log In
3. Fill in 1 character (observe dismiss doorhanger)
4. Close the Log In modal
5. Dismiss doorhanger by choosing to not save the captured password
6. Open the Login form again
7. Type in 1 character
   there is no dismissed doorhanger displayed

The only difference between doing the same steps on virustotal and wego.com is that virustotal requires page refresh while on wego.com its about closing and re-opening the Login form modal. Let me know if you would like a bug submitted to treat the special case from wego.com or not.

Comment 5

[Bianca Danforth [:bdanforth]]

Thanks Timea for verifying and for the question.

When you are entering in a single key the second time, is it the exact same key as before? E.g. if you enter 'k' the first time, do you also enter 'k' the second time? If I enter a different key the second time, or if I enter the same key again the second time (e.g. 'kk' on the second modal), then it works.

Either way, this is an unrelated bug, as the page has already loaded by this point, and we have already successfully shown the dismissed doorhanger once. The bug that I am fixing here is that the password manager code wouldn't run at all on the VirusTotal page, i.e. not even an initial dismissed doorhanger would be shown, much less a second one.

You are correct about this being related to the page refresh. We store the most recent value entered into the password field, and if it hasn't changed, then we don't prompt with the dismissed doorhanger. When you refresh a page, that clears the history of what was last entered into the password field.

I had trouble finding a page with a sign in form that is a modal that has the same behavior as this site, but I imagine this may happen for other sign in modals (particularly formless sign in modals) both before and after Bug 1612258.