When clicking "view saved logins" when standing on an input field, about:logins should automatically write the webpage from where it was opened in the search field
Categories
(Toolkit :: Password Manager, enhancement, P3)
Tracking
()
People
(Reporter: lisamiller9891, Unassigned)
References
Details
Steps to reproduce:
Stand on input field for user/password, where the user has already saved a user/pass in the past.
Click on "View saved logins"
Actual results:
The about:logins page opened in a new tab.
Expected results:
Currently, about:logins just opens and that's that.
Suggestion: Make it so the search field in about:logins automatically searches by default the website in question for the site the about:logins page was opened from.
e.g. I'm on google.com and try to login. I click "view saved logins". about:logins opens up in a new tab, AND in the search field "Google.com" is automatically input, showing me those results.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
I think what you're describing is the old behaviour which was removed in bug 1598464 at UX's request. See also bug 1644963 comment 3.
The problem is that there can be related saved logins that would appear in the autocomplete dropdown but wouldn't appear in the filtered about:logins view since the filter on that page is doing plaintext matching, not considering related domains or subdomains.
Examples:
- User is on https://www.example.com but has a saved login for http://example.com
- User is on https://www.amazon.ca but has a saved login for https://www.amazon.com which they intend to use.
If we decide to go back to pre-filtering IMO:
- we should consider using the eTLD+1 for the filter, not the whole domain since the autocomplete results already include subdomains
- we should also search in the related origins for a login e.g. searching "amazon.ca" would include a login from "https://www.amazon.com" (this can also be confusing though if users think it's a pure string match)
I admit that I still sometimes miss the old behaviour, I'm just clarifying that there isn't a perfect solution here.
Updated•4 years ago
|
Yes, this behaviour is annoying
When we click on View Saved Login, please open the password manager on that specific login (also please allow right click delete&modify)
When you click View Saved login, it just opens the password manager with no search terms now you have to search it again and that will usually means returning to the previous tab (good luck finding it in 800 open tabs) to get the url back
It should be possible to delete and modify(overwrite so you don't have to see it) saved passwords without opening the manager
Comment 4•2 years ago
|
||
Have you considered using only the left-most label of the registrable domain? For example, if the user was on amazon.ca, then “amazon” would be prefilled. This would sometimes result in some false positives, but the best matches would always be at the top, so it would be fine.
Comment 5•2 years ago
|
||
Bug 1810810 allows to open about:logins with preselecting specific login from autocomplete.
Description
•