Open Bug 1699732 Opened 3 years ago Updated 3 years ago

Password panel should handle related logins

Categories

(Toolkit :: Password Manager, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: tgiles, Unassigned)

References

(Blocks 1 open bug)

Details

When either the save password panel or the update password panel appears, the panel should show the appropriate UI when related realms are enabled.

I'm not sure the behavior of the save login panel would change due to related logins, I suppose it would only need to check if a related login exists and show the update text instead if such a login exists.

For the new update panel behavior, if I have a login saved for "facebook.com" with a username of "test" and a password of "test" and I navigate to "messenger.com" and successfully login with a username of "test" and a password of "newTest"...then the update panel should appear with some text that says something like "Would you like to update your login for facebook.com?" and should be pre-filled with "test"/"newTest" (where "newTest" are dots, since this is the current behavior of the update panel). This solves the best case, but what about the worst case?

What happens if I happen to have an airbnb account that I've associated with every related airbnb site (which as of right now is 52 sites)? We would want the user to know which sets of credentials are being updated, but listing 52 sites in a panel would not be possible. We could do something like "Update login for (first entry we find in the related realms list that we have a login for) and (number of other related logins we have for this particular entry)" which seems like a decent compromise for the airbnb case...but appears inadequate when dealing with the beavercreek case.

Beavercreek.com is also related to kirkwood.com, snow.com, and vail.com (among others) and so the previous logic for "Update login for (first entry we find in the related realms list that we have a login for) and (number of other related logins we have for this particular entry)" wouldn't be helpful to the user if they wanted to determine which logins were updated via the panel action. I'm not sure where the compromise is here, to be honest.

Assignee: nobody → tgiles
Status: NEW → ASSIGNED
Priority: -- → P1
Severity: -- → N/A

Setting to P2 based off priority definition. I don't believe this will land in this release cycle (Fx 88)

Priority: P1 → P2
Priority: P2 → P3
Assignee: tgiles → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.