1531651 - Munged username saved on td.com

Status: VERIFIED FIXED

(Toolkit :: Password Manager: Site Compatibility, defect, P3)

Description

[Vicky Chin [:vchin]]

On www.td.com, when a user enters the user name, clicks "Remember Me", and saves the password using the Password Manager, the username for the entry in the Password Manager is the username as hidden by the site e.g. 123456******1234 instead of the actual username 1234561234561234.

This causes the next entry to login to the website to fail and the login button does not work.

Manually overriding the username for that entry restores site function.

Comment 1

[Matthew N. [:MattN]]

Note that when we ask to save the password you can correct cases like this before clicking the save button. We're working on not saving the incorrect username in H1.

Comment 2

[Daniel Bodea [:danibodea]]

The test case link above (www.td.com) does not have a login form or I do not find it. Can you confirm?
Furthermore, could this issue be verified with the test case link (https://nb.fidelity.com/public/nb/401k/home) like for bug 1427624?

Thanks!

Comment 3

[Matthew N. [:MattN]]

I think the actual login happens from https://easyweb.td.com/ which redirects to another subdomain.

Comment 4

[Matthew N. [:MattN]]

Vicky, can you confirm that the username field is now blank in the prompt to save in Nightly?

Comment 5

[Daniel Bodea [:danibodea]]

The https://easyweb.td.com/ website has different login pages with different sub-domains:

1. Online banking: https://onlinebanking.tdbank.com/#/authentication/login
   The username is being munged after input so the username is not being saved along with the password and the autofill works correctly (obviously, only auto-filling the password).
2. Easy Web: https://authentication.td.com/uap-ui/index.html?consumer=easyweb&locale=en_CA&execution=e3s1#/login/easyweb-getting-started
   The username is not being saved along with the password because the "Description" field is recognized as the username, saving it's contents as the username. This is certainly incorrect, but I don't know whether this is an acceptable edge case; Need confirmation. The autofill works but fills the "Description" field's contents with it's intended string instead of the username field.
3. WebBroker: https://wb.authentication.td.com/uap-ui/index.html?consumer=webbroker&locale=en_CA#/login/webbroker-getting-started
   The username and password are correctly saved and auto-filled.
   The other login pages were on other origins.

Considering the 3 logins above, only the 1st one is relevant to the testing of this bug.
Considering that the munging of the username string happens right after the string is input, I doubt that the unmunged username string can be saved instead of the munged one. Anyway, I see that the intended behavior is to avoid saving a munged username at all, only saving the password, leaving the username field in the pop-up to save the credentials as blank (this does allow the user to manually input the correct username before saving the credentials).

@Matt: This bug appears fixed by the change in bug 1427624. It should probably be closed as WORKSFORME or DUPLICATE.
@Vicky: Can you confirm the behavior I described above with a valid(existing) account?