1630858 - about:logins Windows re-authentication dialog seemingly randomly asks for the username and/or password rather than biometrics

Status: NEW

(Firefox :: about:logins, defect, P3)

Description

[Matthew N. [:MattN]]

When I want to reveal/copy/edit a saved password (with a master password) and get the Windows dialog to re-authenticate, I seemingly randomly get three different variants of the dialog:

• Defaulting to using a PIN but with the option to use a password (ideal/expected)
• My account user pre-selected with a textbox to enter a password
• Blank username and password fields but with my username behind the More Choices options

I'm testing on Windows 10 with an account linked to my Microsoft Account.

I can't figure out the pattern to it but here are some ideas:

• The repeated failing calls to check if the password is empty are causing Windows to act like the previous authentication failed? We should maybe cache this. I think I saw that Chromium is. Edit: filed as bug 1631879.
• We aren't properly initializing the credential UI code properly so some uninitialized memory is getting used and causing the seemingly random result?

I do get the PIN option sometimes so this doesn't seem the same as bug 1624255.

Comment 1

[Jonathan Guerin]

@MattN - I work for MSFT. Let me know if you don't get traction addressing this, I can try to find the right folks in Windows.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

[Tracking Requested - why for this release]: Unexpected and confusing behavior for users on Windows in a new feature, unknown how common this is.

Comment 3

[Matthew N. [:MattN]]

(In reply to Matthew N. [:MattN] from comment #0)

• The repeated failing calls to check if the password is empty are causing Windows to act like the previous authentication failed? We should maybe cache this. I think I saw that Chromium is.

Btw. I tried running the autoland build before bug 1622542 to test this theory but it was even worse, always defaulting to the username+password empty with the PIN option seemingly randomly appearing in More Choices.

Comment 4

[Matthew N. [:MattN]]

We are actively discussing this and bug 1624255 with Microsoft. It's on me to provide some logs for them today because Jared can't repro the issue.

Comment 5

[Matthew N. [:MattN]]

After upgrading to Windows 10 1909 (from 1809) I'm not able to reproduce this yet. Still investigating and I will ask MSFT whether this was a known issue in 1809.

Comment 6

[Matthew N. [:MattN]]

I just asked Microsoft if this was fixed in 1909 and sent the Feedback report with logs from my 1809 VMs that still experience this and bug 1624255 (only intermittently).

I get slightly different behaviour in a local account vs. a Microsoft account.

Comment 7

[Matthew N. [:MattN]]

Microsoft didn't answer whether this was a known issue in 1809 but did acknowledge receipt of my Feedback Hub reports.

In my new Edge VM that is still on 1809 I captured the recordings:

In the local account it kept flipping defaults between PIN and password entry (no username entry, which is good):
https://aka.ms/AA88vrc
In the account connected to my personal Microsoft account it sometimes defaulted to showing a blank username AND password field:
https://aka.ms/AA88vsw

I have video recordings of both of these scenarios I can share, if needed. They were sent to MSFT.

At this point it seems like we can add a note to SUMO that upgrading to Windows 10 1909 will address some problems… otherwise we could not ship this feature to earlier versions but then our behaviour would be even more confusing across OS versions.

Comment 8

[Matthew N. [:MattN]]

RyanVM sent me a breakdown of which Windows 10 versions our users are on and given that <1803 usage is low I think we're fine to ship. Ryan also suspects the issue would have been fixed in 1903 as 1909 was a minor release on top of that.

Also I calculated that a maximum of 0.56% of all users would see the OS-reauth dialog per day across all OSs. If we see issues in the gradual rollout in the first few days then we can address this.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

This feature was disabled for 76/77 via bug 1636511. Updating the status flags accordingly.

Comment 10

[Cosmin Muntean [:cmuntean], Ecosystem QA]

I have managed to install Windows 10 Home version 1809 OS build 17763.379 on a virtual machine and verified if I can reproduce this behavior. Here are the results:

Local account (administrator) - Sign-in options normal account with password + PIN code

• When trying to show/copy/edit a password from about:logins the OS auth dialog requires my PIN code, but after a few attempts OS auth dialog requires the account password and there is not PIN option in the "More choices". This seems to be random since I can reproduce it when entering the valid password, or when entering the wrong password, or canceling the OS dialog.
  I have tested this on Windows 10 1903 and Windows 10 1909 and I can confirm that this issue is not reproducible on these versions.

Local account linked to a Microsoft email account (administrator) - Sign-in options: account linked to a Microsoft account + PIN code

• When trying to show/copy/edit a password from about:logins the OS auth dialog requires entering the username and the password. Both fields are blank (this seems to be another issue). If I choose "More choices" the email account is listed and can be used, but there is no PIN option.
• After a few attempts, the OS auth dialog asks for the PIN code. So this seems to also be random. Sometimes the OS auth requires username and password (both blank fields) and sometimes the PIN code.

If I remove the PIN code, the OS auth dialog always requires to enter a username and a password (the fields are blank). If I enter the Microsoft email account and the email's password in the blank fields, the OS auth accepts these credentials and the password is shown/copied or the edit mode is opened. But is confusing since you don't know exactly what credentials should be used. I have logged this behavior in Bug 1640925.

I have encountered the mentioned behaviors on both Firefox 76.0.1 release and the latest Nightly 78.0a1 build on Windows 10 Home version 1809.

@Matt please let me know if you need any information.

Comment 11

[Jonathan Guerin]

We believe that this is fixed in 2004. Can you please attempt the repro on that build?

Comment 12

[Cosmin Muntean [:cmuntean], Ecosystem QA]

In this report there are two different behaviors and I have tested both on 3 different Windows versions (Windows 10 Home version 1809 OS build 17763.379, Windows 10 PRO version 1903 OS build 18362.836 and Windows 10 Pro version 2004 OS build 19041.264). Here are the results:

1. The first bug encountered:

• If you have an OS password and also a PIN code, the OS auth dialog randomly require to enter the password or the PIN code. This issue is also reproducible if you have an account linked to a Microsoft Account.
  I have managed to reproduce this issue only on Windows 10 Home version 1809 OS build 17763.379. The issue is not reproducible with Windows 1903, 1909, and 2004. So probably this was fixed started with Windows 10 1903.

2. The second bug encountered:

• Blank username and password is the default option of the OS auth when having an OS account linked to Microsoft Account. For tracking purpose I have logged this in a separate bug: Bug 1640925.
  I have managed to reproduce this issue on all 3 Windows versions inclusive Windows 10 version 2004.
  However, I have observed that on Windows 10 Pro version 2004 OS build 19041.264 if you don't have a PIN code only the account linked to the Microsoft account, the OS auth requires by default blank username and password and there is no "More choices" option. But if you add a PIN code, the "More choices" option is available but the email account is not listed there.
  I have added more information about this in Bug 1640925 and shared the screenshots with you Jonathan.

@Jonathan about which of the described issues did you refer?

Comment 13

[Jonathan Guerin]

Cosmin - I'm referring to the first bug, and glad to hear that it doesn't reproduce. The folks from that team are following up with MattN via email (I'm not on this team, I just randomly found this bug while looking at 'This week in Firefox' :) )

Comment 14

[Julien Cristau [:jcristau]]

Bug 1641473 made this nightly-only so it won't ride the trains to beta next week.

Comment 15

[ragimeg698]

The key to copy links is broken. It was broken in 88 and remains unfixed.

Copying links is a core function of a web browser. It is completely unreasonable that this function should be removed. Tens, maybe hundreds of millions of people use hotkeys. It is an absolutely normal, absolutely acceptable way to interface with a computer. All of those people have had to find solutions outside of Firefox, and for absolutely no reason.

A "replacement" key that is not physically usable is obviously not a replacement.

Since my legitimate reports about this critical bug are being removed, I'm leaving comments on other people's bugs.

Firefox currently has no hotkey to copy links.

---

Comment 16

[Mahyar]

Hi
thank ypu guys. I set google recaptcha authenticator for WP CMS login page. but in Mozila it is not working sometimes. "failed to load javascript"
but javascript is run.
my website:
https://loolehetesalat.com/
can you help me for login page?