Don't automatically show only the View Saved Logins footer upon focusing a non-empty secure password field
Categories
(Toolkit :: Password Manager, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox66 | --- | unaffected |
firefox67 | --- | verified |
firefox68 | --- | verified |
People
(Reporter: MattN, Assigned: MattN)
References
Details
(Keywords: parity-chrome, parity-safari, Whiteboard: [passwords:fill-ui])
Attachments
(2 files)
Two conditions:
- The password field is non-empty.
- We're on a secure page so don't need to show the insecure warning.
Since the field is non-empty we shouldn't be showing login suggestions (we don't filter the logins based on the password field value for obvious reasons) and auto-showing just the footer gets in the way of the page.
Chrome seems to have this same bug but only when the field was autofilled by Chrome (not if the user has some other non-empty value there) as in that case they show the login suggestion of what was already filled (not sure why). I didn't test with the password field auto-focused by the page which may be handled differently.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
If the field is insecure then we do want to show the footer below the insecure warning.
Assignee | ||
Comment 2•6 years ago
|
||
Comment 4•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Verified as fixed on Nightly 68.0a1 / 2019-03-26 Mac 10.14, Windows 10, Ubuntu 16.04.
I also checked on 67.0b4 / 2019-03-22 Win 10, the View Saved Logins footer is disabled by default by "signon.showAutoCompleteFooter" pref. and turning it on, the behavior is as expected.
Comment 6•6 years ago
|
||
Given that there are no passwords stored for that particular site or no passwords at all, the "View Saved Logins" footer showing might be a bit confusing.
This is a very polishy detail and I'm not sure if there are cases where showing it in the above scenario makes sense? Is the scenario in which an user resets the address filter for "saved logins" to get an user/password from a different site?
Matt, thoughts on the above ? aka do you think we might want to fix that case?
Updated•6 years ago
|
Assignee | ||
Comment 7•6 years ago
|
||
(In reply to Adrian Florinescu [:adrian_sv] from comment #6)
Given that there are no passwords stored for that particular site or no passwords at all, the "View Saved Logins" footer showing might be a bit confusing.
This is a very polishy detail and I'm not sure if there are cases where showing it in the above scenario makes sense? Is the scenario in which an user resets the address filter for "saved logins" to get an user/password from a different site?
Matt, thoughts on the above ? aka do you think we might want to fix that case?
I don't understand what you're asking? Are you asking about a case that's different from the summary? Maybe bug 1538952?
Comment 8•6 years ago
|
||
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #7)
(In reply to Adrian Florinescu [:adrian_sv] from comment #6)
Given that there are no passwords stored for that particular site or no passwords at all, the "View Saved Logins" footer showing might be a bit confusing.
This is a very polishy detail and I'm not sure if there are cases where showing it in the above scenario makes sense? Is the scenario in which an user resets the address filter for "saved logins" to get an user/password from a different site?
Matt, thoughts on the above ? aka do you think we might want to fix that case?I don't understand what you're asking? Are you asking about a case that's different from the summary? Maybe bug 1538952?
Yes, I was referring to something on the same lines of bug 1538952, which I initially thought it handles something else and not related to this bugs' summary.
Assignee | ||
Comment 9•6 years ago
|
||
This bug is about non-empty, bug 1538952 is about empty.
Description
•