1576148 - Duplicate autosaved generated passwords are stored with different formActionOrigin

Status: RESOLVED DUPLICATE of bug 631272

(Toolkit :: Password Manager, defect)

Description

[Adrian Florinescu [:aflorinescu]]

Attachment: 2019-08-23_14h58_43.mp4

[Environment:]
Ubuntu 16.04, Windows 10, Windows 7, (untested on Mac).
70.0a1 2019-08-22

[Steps:]
I.
1. New profile. (not required)
2. Open facebook.com
3. Use generate password on password field from login and also on the New password field.

II.
1. New profile. (not required)
2. Open imgur.com/signin and generate a password.
3. Open imgur.com/register and generate a password.

[Actual Result:]
The same duplicated autosaved generated passwords are stored.

[Expected Result:]
Not entirely sure what the expected behavior should be here.

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

That seems a bit awkward. What happens if you change one of the passwords for a site? Do both the copies change?

Comment 2

[Adrian Florinescu [:aflorinescu]]

(In reply to Liz Henry (:lizzard) from comment #1)

That seems a bit awkward. What happens if you change one of the passwords for a site? Do both the copies change?

From what I can tell, they are not literal copies, hence Fx treats them as two different records, which somehow raises the awkwardness when this happens (due to the fact that both records have blank usernames and same generated password). So, when you update a u/p from doorhanger, you will only update the one u/p record for which the doorhanger has been generated. If you edit from about:logins, it will also change just the one you are editing on.

Not particularly sure either on how often this kind of scenario might be reproduced in a live environment.

Comment 3

[Matthew N. [:MattN]]

This is a case where debug logs would have been helpful btw. but I tested the sites myself and identified the issues.

Is this specific to password generation or does it happen the same if you fill those forms manually? Perhaps the doorhanger normally ignores the formActionOrigin and relies on the username but the auto-saving may take the formActionOrigin into account. From what I can tell the behaviour is the same.

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

I.
1. New profile. (not required)
2. Open facebook.com
3. Use generate password on password field from login and also on the New password field.

The former has a form action origin of https://www.facebook.com whereas the latter has https://m.facebook.com so it's expected that Firefox stores them as "duplicates". If you inspect logins.json you will see those two values. This has been a longstanding confusing issue for users since we never show this field to users (because it would be confusing to understand). Matching on the formActionOrigin is a security feature (bug 360493) and we have talked about removing it bug 1121119 but the security team didn't want to yet.

II.

1. New profile. (not required)
2. Open imgur.com/signin and generate a password.

formActionOrigin: https://imgur.com

3. Open imgur.com/register and generate a password.

formActionOrigin: javascript:

Similar case here.

This is kinda a longstanding issue (maybe made somewhat worse with auto-saving?) and we haven't come up with a good solution over the years. I personally want to remove this field but since we can't do that I also don't think we should show this field to users (it would show two origins for each login).

Comment 4

[Adrian Florinescu [:aflorinescu]]

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

Is this specific to password generation or does it happen the same if you fill those forms manually? Perhaps the doorhanger normally ignores the formActionOrigin and relies on the username but the auto-saving may take the formActionOrigin into account. From what I can tell the behaviour is the same.

Yup, same behavior for manual input, so it's not only generated passwords.

This is kinda a longstanding issue (maybe made somewhat worse with auto-saving?) and we haven't come up with a good solution over the years. I personally want to remove this field but since we can't do that I also don't think we should show this field to users (it would show two origins for each login).

For manual input, I would think that the use-cases are probably more reduced in number than for generate, since usually, there are validations and such, so it should be harder to reach the point in which you get this specific case. In generation case, you have no validation on auto-save, so you just need to generate twice and you hit it. I concur with the last part though, showing the formActionOrigin doesn't seem like the right direction for improving user experience.