-
Notifications
You must be signed in to change notification settings - Fork 80
Enter key to autocomplete #40
Comments
Hey @emersion, You mean when there's only one result? Because in the current set-up, you should be able to cycle through the search results using TAB and then hit ENTER to submit login form with the selected login details. |
It would be cool to submit the first result when the enter key is pressed. Another idea of useful keybinding would be to be able to cycle through results using arrow up/down. |
The issue I have with immediately submitting the first result on ENTER is that is has to be super clear that the search field lost focus, otherwise people may end up sending login credentials to the wrong site when they meant to simply issue another search. There shouldn't be too much magic there, imo. I can definitely see up/down arrows (in addition to TAB) being helpful though. 🥇 |
A safer way to implement this could be to only fill on ENTER if the current domain is still the one extracted from the tab's URL. |
I think there is a simple way of resolving this issue: When a user hits shortcut to open the popup for the first time, if there is any match at all, the focus should be on the first match, and not on the search box. If there are no matches, the cursor stays on the search box for the user to type some request. |
Even if there are multiple matches, it should be easy to just go for the first, even if the search box is highlighted. I think visually, this is best done by selecting the first entry (highlighting it), leaving the cursor in the search box, but letting up/down move the selection around, while Enter then simply picks the selected item. This will be especially necessary in the context of #32 (i.e. fuzzy searching). |
This might be a bit confusing, because hitting Enter while cursor is in the search box can mean two things: "do the search" and "submit the first entry". For clarity from the user perspective I'd prefer keeping focus on the thing that Enter is going to affect - if cursor is on the search box, do the search, if cursor is on a focused entry, select it. |
How about the following?
This seems like it would be a fairly intuitive workflow, and allow using enter for both search initiation and submitting results for autofill. |
Or an alternative approach could be:
|
I guess I'd have to play with this to be sure, but right now it sounds a bit "too much" and prone for errors, e.g. I could type a search term, accidentally hit Enter twice and unintentionally leak wrong credentials to the website. The approach that I described above just feels simpler, in my opinion. The difference between yours and mine approaches is that in my case an entry is selected first, not the search box, and so if you want to search you'd have to press Up or Shift+Tab first. But I'm asking myself, why would I want to search for a password if browserpass found some candidates? The whole point of browserpass is that it detects URL and suggests correct candidates, thus saving me from phishing attacks. If browserpass did not find any candidate, then sure, I can use search - and in that case the cursor will be on the search box. |
I fairly commonly want to search for something, because on some domains I have a large number of accounts which match, and it's far faster to search than it is to scroll down the list looking for the one I want.
Perhaps it could be optional? This extension already supports optional autofill, which is even more prone to credential leakage, as it requires no select-the-correct-credential input from the user at all. What about this workflow?
This would mean that "press enter twice" always results in an autofill (provided there is a login available in the list), and pressing it once never does. |
The search should happen incrementally and not require Enter in the first place, I'd say… |
I don't fully understand what the outcome of the discussion on #211 actually was - there were a few different concepts that were mentioned there. Are you able to clarify the intended behavior for that? Basically the main things I want to avoid are:
|
I mentioned this in #211:
The point of #211 is that you have much less entries for one domain comparing to the entire list of entries in your password store, that's why real-time filtering will not be as weird as real-time search. Also, on an engineering note, filtering can be done directly in browser extension, while search is an expensive operation that requires communicating with backend app and traversing password-store directory. You probably haven't tried browserpass on Windows, but unfortunately it is considerably slower, I saw that search operation sometimes takes 1-2 seconds to complete in a rather small password store.
A few ideas for visual design are mentioned there, but the main concept is unchanged - clearly differentiate "search" and "filter", and make "filter" work in real-time.
I believe these two points cover all of your requirements: ☑ Filtering will be in real-time (and much faster than search, as I mentioned) I suggest we move further discussion on filtering in #211, so that it's easier to find in the future. |
Hm, but now I'm rethinking this again, and after #211 since filtering will be in real-time, users will never need to press Enter, so there is nothing to confuse it for, and there is no way to accidentally press it twice - with real-time filtering you press Enter if and only if you want to submit the top result. Therefore, I'm taking your suggestion and adjusting it a bit for the filtering scenario:
Thoughts? |
This sounds perfect. I like it! |
Now we only need to find a brave person to implement the filtering 😉 😄 |
@mazimbaz That is exactly what I had in mind too. \o/ |
Looks like nobody else is tackling this one, so I will do it :-). |
This would be awesome! Since #211 is kind of a required dependency, would you be willing to help out with implementing it first? I will help out with whatever I can. |
@maximbax I did both in one go - see #220 :-). |
Just do it when the enter key is pressed.
The text was updated successfully, but these errors were encountered: