1540154 - The email is not being saved by the Password Manager on Netflix login, only the password

Status: VERIFIED FIXED

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

Description

[Daniel Bodea [:danibodea]]

Attachment: log of mozregression gui when regressing issue.txt

Note
*
Affected versions

• Nightly v68.0a1
• Beta v67.0b5
• Release v66.0.2

Affected platforms

• Windows 10
• Mac OS 10.13.6
• Ubuntu 16.04

Steps to reproduce

1. Open Firefox with a new profile.
2. Reach: https://www.netflix.com/ro-en/login
3. Input any strings inside the input boxes (username, password).
4. Click the "Sign In" button.
5. A pop-up asking the user to save credentials is displayed.

Expected result

• Both the email and password are being saved by the Password manager.

Actual result

• Only the password is saved, no email is saved along with the password.

Regression range

• This appears to be a recent regression because this issue does not occur on the Release version Firefox v66.0.2.
• The mozregression gave out the "Unable do bisect" error, but the mozregression log should be enough to determine the regressor. Log is attached to this bug.

Additional notes:

• The username does not get saved by the Password Manager for this site (*https://authet15.alipay.com/login/index.htm) also, BUT it does not seem to be a regression like in the case of Netflix.

Comment 1

[Matthew N. [:MattN]]

[Tracking Requested - why for this release]: Regression on major site. Issues likely affects many others.

Site compatibility bugs should have the URL field filled.

Pushlog from the attachment: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=67424fa7&tochange=e571d003

That includes bug 917325. Sam, can you investigate?

danibodea, for the future you should always include debug logging for password manager issues with a website. The link is in the component description: https://wiki.mozilla.org/Toolkit:Password_Manager/Debugging

Comment 2

[Daniel Bodea [:danibodea]]

Attachment: netflix browser console log.txt

I have enabled the logging by flipping the "signon.debug" pref to true and activating all the log types from the Browser Console (Errors, Warnings, Logs, Info, Debug, CSS, XHR, Requests). Then I went to the Netflix website and logged in with a valid account. Only the password was saved, the email address was not. Then I signed out and went back to the login page. Only the password was auto-filled. Clicking on the "Email or phone number" filed, it can be observed that the password manager does not recognize the field as a username field.

The log is attached in a text file.

Comment 3

[Matthew N. [:MattN]]

Sam, actually I'll take this one while you take the MP ones.

Comment 4

[Matthew N. [:MattN]]

The problem is that Netflix is using autocomplete="email" on their username field which is incorrect for two reasons:
a) the placeholder says "Email or phone number" so phone numbers are also accepted
b) autocomplete="username" is more appropriate

<input type="text" data-uia="login-field" name="userLoginId" class="nfTextField error" id="id_userLoginId" value=""
       tabindex="0" autocomplete="email" dir="">

We can likely ask them why they're doing that but I'm going to see if other recent username detection issues were also due to autocomplete="email". If so, then maybe we need to added it as a valid option… then it begs the question if whether "tel" should also be added for sites that use phone numbers as usernames… These additions would make the fix for bug 917325 less effective in cases where a autocomplete="tel" or autocomplete="email" are not used as a username but are closer in a registration form.

Comment 5

[Matthew N. [:MattN]]

Mike, should we ask Netflix on mozilla-netflix-discuss to remove the autocomplete attribute on their login page or replace it with the value of username? The value of email shouldn't be causing any benefit but does cause harm in Firefox since autocomplete="email" shouldn't be used for username fields, especially when the field doesn't only accept email addresses.

I've looked through other recent reports and haven't seen other sites affected but I won't be surprised if there are a few in the world… I'd rather not put in a general workaround for this since it will break password manager on sites that have registration forms like so:

Username: [baz        ]
Email:    [[e-mail]]
Password: [*******    ]

Any opinions on whether we should workaround this? Is it worth digging through http archive data for autocomplete="email" and trying to determine how often it's used on a username field?

Comment 6

[Mike Taylor [:miketaylr]]

Here's the results from BigQuery (the httparchive.response_bodies.2019_01_01_desktop table): 350 sites, https://docs.google.com/spreadsheets/d/16VzhQS3sP6NuHEF1AB83apenM7tlxaU6V44hhbFe1IQ/edit#gid=254666868

note: 120 of them are some spammy ad thing, https://d2i6wrs6r7tn21.cloudfront.net/sources/8974/iframe.1538497952.html

Let me shoot an email to Netflix, I'll cc you.

edit: here's the query i used on BigQuery:

SELECT page,url FROM `httparchive.response_bodies.2019_01_01_desktop`
WHERE REGEXP_CONTAINS(body, r'autocomplete=*?email')
ORDER BY url;

Comment 7

[Matthew N. [:MattN]]

Thank you very much Mike for the email and data.

I analyzed the data from 64 pages and found that about 10% of the data set is using autocomplete="email" when autocomplete="username" should be used. That makes me think that we should allow it to be treated as a username even though it may cause us to go back to pre-68 behaviour of saving the wrong field during registration.

https://docs.google.com/spreadsheets/d/1kgYb7RK0DKyq4DrklsTo1d4zWNJpP6OIIgKruCwDRBk/edit#gid=254666868

P.S. I still think it's good for Netflix to fix this for the reasons I said in comment 5 so the email wasn't for nothing.

Comment 8

[Matthew N. [:MattN]]

Attachment: Bug 1540154 - Allow autocomplete=(email|tel|tel-national) to be username fields. r=sfoster

Some sites use email, tel and tel-national values for @autocomplete even when they are used as the username and 'username' would be more appropriate.

We already allowed type=email / type=tel so allowing the autocomplete equivalents is reasonable.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/903c6563775a
Allow autocomplete=(email|tel|tel-national) to be username fields. r=sfoster

Comment 11

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/903c6563775a

Comment 12

[Matthew N. [:MattN]]

Comment on attachment 9055350 [details]
Bug 1540154 - Allow autocomplete=(email|tel|tel-national) to be username fields. r=sfoster

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Bug 917325
• User impact if declined: Usernames will not be filled or saved on Netflix.com and some other sites
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Bug 917325 only allowed certain @autocomplete values from being a username field… this change is expanding that list making it behave closer to the pre-917325 behaviour. It's a trivial straightforward change with almost no chance of making things worse than pre-917325.
• String changes made/needed: None

Comment 13

[Pascal Chevrel:pascalc]

Comment on attachment 9055350 [details]
Bug 1540154 - Allow autocomplete=(email|tel|tel-national) to be username fields. r=sfoster

Tracked regression in 67, webcompat fix for a top site, low risk patch with tests, uplift approved for 67 beta 9, thanks.

Comment 15

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2c01eafb7bb8

Comment 16

[Daniel Bodea [:danibodea]]

This issue was fixed and verified in Nightly v68.0a1 and Beta v67.0b9.
Thank you.

Comment 17

[Adrian Florinescu [:aflorinescu]]

Attachment: alipay.txt

The problem on alipay.com (https://authet15.alipay.com/login/index.htm) - (note in comment0) is still reproducible, even with the fix which fixes the @ issue for netflix.
Attaching a debug log for it and I would assume that this is a different issue @ hand, for which in my view a new bug should be opened, if one doesn't exist already. Matt, can you take a look at the log?

Comment 18

[Matthew N. [:MattN]]

Yes, please open a separate bug… I ignored that part since it wasn't a regression.