Based on the _onPasswordEditedOrGenerated callback, a dismissed doorhanger should appear when:

• The user edits a password field (This will be fixed by Bug 1638587)
• The user edits a username field, when a matching password field has already been filled (This bug)

(There may be other cases as well that I'm not aware of yet.)

Currently, neither of these cases work when the username and password fields are each in their own shadow root (e.g. https://www.virustotal.com/gui/sign-in from Bug 1634819).

This bug is concerned with fixing this for the second case described above when the username field is edited.

STR:

1. Go to https://www.virustotal.com/gui/sign-in
2. Enter some value(s) into the password field
3. Blur the field.
4. If a key icon displays in the URL bar (i.e. if Bug 1638587 is resolved), click the key icon and in the doorhanger, click "Don't Save" to remove the key icon and doorhanger.
5. With the password field non-empty, enter some value(s) into the username field
6. Blur the field

Actual results:
There is no key icon in the URL bar.

Expected results:
There is a key icon in the URL bar.

This also fails to show the dismissed doorhanger when the username field is edited, then the password field is edited and blurred. This patch should fix both of these cases.

Root cause
When the "input" event fires in this case, getUserNameAndPasswordField incorrectly returns null for both the username and password fields, as it relies on _getFormFields , which relies on _getPasswordFields, which relies on formLike.elements, which is wrongly [] (i.e. an empty array) for this Shadow DOM test case.