Closed
Bug 1275113
Opened 9 years ago
Closed 9 years ago
Handle HTTP and HTTPS logins with different passwords for the same username when filling
Categories
(Toolkit :: Password Manager, defect)
Toolkit
Password Manager
Tracking
()
RESOLVED
DUPLICATE
of bug 667233
People
(Reporter: MattN, Unassigned)
References
Details
We should decide how to handle the following case when doing scheme upgrades:
==== Origin ======== Username == Password ==
http://example.com myusername myOldPassword
https://example.com myusername myNewPassword
and similarly for when there is no username.
Consider:
* empty usernames / no username field (only way to fill would be the context menu)
* if we return both then we won't auto-fill. We could prefer the matching scheme one or the last changed?
* if we want to autocomplete both (no auto-fill), if and how do we want to distinguish the menu entries?
We already dedupe if the password is the same so we don't need to worry about that case.
Comment 1•9 years ago
|
||
For the purposes of bug 667233, we would have the https entry so we wouldn't even look at the http entry. Hence, that bug doesn't have to be blocked on this one. This bug could just be an enhancement on top of that.
Some Options:
1) Throw away HTTP entry if HTTPS entry exists
2) Upgrade HTTP entry to HTTPS
3) Continue autofilling HTTPS entry for myusername if one username exists. If more than one exists, us the autocomplete drop down and signify the HTTP entry with some TBD icon.
4) Use autocomplete experience as if there were multiple usernames. Signify HTTP entry with some TBD icon.
Reporter | ||
Comment 2•9 years ago
|
||
(In reply to Tanvi Vyas - behind on reviews [:tanvi] from comment #1)
> For the purposes of bug 667233, we would have the https entry so we wouldn't
> even look at the http entry. Hence, that bug doesn't have to be blocked on
> this one. This bug could just be an enhancement on top of that.
Right, I marked this bug as blocking that one like we do for follow-up bugs so we could improve the experience for this case.
> Some Options:
> 1) Throw away HTTP entry if HTTPS entry exists
I filed this bug about filling but this sounds like something we would do at capture time (e.g. bug 1127579).
> 2) Upgrade HTTP entry to HTTPS
> 3) Continue autofilling HTTPS entry for myusername if one username exists.
> If more than one exists, us the autocomplete drop down and signify the HTTP
> entry with some TBD icon.
> 4) Use autocomplete experience as if there were multiple usernames. Signify
> HTTP entry with some TBD icon.
What I originally implemented in bug 667233 was #3 (and/or #4 which sounds the same to me) but it gets confusing when two login has the same username in autocomplete. We can use dates or icon to help distinguish them but it seemed like it would get busy/crowded especially on narrow fields since the autocomplete dropdown width matches the field width.
After talking with Dolske, I implemented only showing the matching scheme (HTTPS) if there is an upgrade. This means we won't ever currently show the same username twice in autocomplete. This matches the etherpad proposal[1]:
* Autofill HTTP on HTTP (even if a HTTPS record exists)
* Autofill HTTP on HTTPS if there is no HTTPS record.
* Autofill HTTPS on HTTPS (even if a more recent HTTP record exists)
[1] https://old.etherpad-mozilla.org/same-domain-http-https-passwords4
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•