1541044 - Username autocomplete not attached to field when a login is saved after the field is created

Status: NEW

(Toolkit :: Password Manager, defect, P5)

Description

Attachment: debug.txt

[Environment:]
This issue reproduces across all the tested platforms - Windows 10 / Mac 10.14 / Ubuntu 16.04 with 67.0b7 - 2019-03-31 and 68.0a1 - 2019-04-02.

[Description:]
Preconditions:

• first time saved password on the target site;
• login form does not redirect (either invalid password or any other similar scenario in which a redirect doesn't happen)

[Steps to reproduce:]

1. Open https://www.reddit.com/
2. Click on the "Log in" button.
3. Input fake user/password.
4. Use password manager to save them.
5. Delete the values from the fields (both from username and password)
6. Focus username and focus password.
7. Reload the page or just re-select the username.
8. Focus username and focus password.

[Actual Result:]
6. Username is displayed as a history/autocomplete (no "view saved logins" footer) and no password manager style key showing it's a saved password manager value) / password is displayed properly with the password manager style and footer.
8. Username and password are displayed with "view saved logins" footer

[Expected Result:]
In both 6. & 8. use-cases the username/password are displayed with the password manager style and footer.

[Note:]

1. My assumption is that this is a small edge case remaining from bug 1189618, hence I don't think it is a regression or that it applies to Fx66.
2. I'm not particularly sure how much the log would help, but attaching one nevertheless.

Comment 1

[Matthew N. [:MattN]]

(In reply to Adrian Florinescu [:adrian_sv] from comment #0)

[Description:]
Preconditions:

• first time saved password on the target site;
• login form does not redirect (either invalid password or any other similar scenario in which a redirect doesn't happen)

[Steps to reproduce:]

1. Open https://www.reddit.com/
2. Click on the "Log in" button.
3. Input fake user/password.
4. Use password manager to save them.
5. Delete the values from the fields (both from username and password)
6. Focus username and focus password.
7. Reload the page or just re-select the username.

Reloading the page or even the login overlay works fine for me. Can you confirm the same?

Focusing the field after the first save without a reload not showing the login autocomplete is a longstanding behaviour.

8. Focus username and focus password.

[Actual Result:]
6. Username is displayed as a history/autocomplete (no "view saved logins" footer) and no password manager style key showing it's a saved password manager value) / password is displayed properly with the password manager style and footer.
8. Username and password are displayed with "view saved logins" footer

[Expected Result:]
In both 6. & 8. use-cases the username/password are displayed with the password manager style and footer.

[Note:]

1. My assumption is that this is a small edge case remaining from bug 1189618, hence I don't think it is a regression or that it applies to Fx66.

If the STR what I think they are then this is an issue we've had since the beginning of password manager.

2. I'm not particularly sure how much the log would help, but attaching one nevertheless.

It was helpful :)

Comment 2

[Adrian Florinescu [:aflorinescu]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #1)

Reloading the page or even the login overlay works fine for me. Can you confirm the same?

Focusing the field after the first save without a reload not showing the login autocomplete is a longstanding behaviour.

Yes, AFAIK, the issue only reproduces when you don't reload or the login doesn't redirect. I think that this issue gets a bit more visible with the introduction of the "view saved logins" footer and the overall pass manager style.

Comment 3

[Matthew N. [:MattN]]

OK, so I guess the STR is wrong and I will update it to remove the reload mention.

I agree it's a bit for visible with the footer but the key icon would previously indicate this bug too.

If we want to fix this we should be careful not to regress username suggestions via form history for users when they don't have a saved login.

Comment 4

[Adrian Florinescu [:aflorinescu]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #3)

OK, so I guess the STR is wrong and I will update it to remove the reload mention.

The steps are correct. I added 7-8 for comparison reason. As that was confusing: steps 1-6 are for reproducing the issue, 7-8 are for restoring proper expected behavior. For better clarity, we could strike trough str. 7-8.