Skip to content
This repository has been archived by the owner on May 27, 2019. It is now read-only.

Enter key to autocomplete #40

Closed
emersion opened this issue Feb 10, 2017 · 22 comments · Fixed by #220
Closed

Enter key to autocomplete #40

emersion opened this issue Feb 10, 2017 · 22 comments · Fixed by #220

Comments

@emersion
Copy link
Contributor

Just do it when the enter key is pressed.

@dannyvankooten
Copy link
Collaborator

dannyvankooten commented Apr 10, 2017

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.

@emersion
Copy link
Contributor Author

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.

@dannyvankooten
Copy link
Collaborator

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. 🥇

@fmeum
Copy link

fmeum commented Apr 19, 2017

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.

@maximbaz
Copy link
Member

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.

@madduck
Copy link

madduck commented Feb 27, 2018

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).

@maximbaz
Copy link
Member

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.

@erayd
Copy link
Contributor

erayd commented Feb 27, 2018

How about the following?

  • If the search box is empty, enter autofills the first entry.
  • If the search box contains text, then:
    • If the search has not yet been run, run the search
    • If the search has been run, and has not been edited since running, autofill the first entry.
    • If the search has been run, but has since been edited, run the search again.

This seems like it would be a fairly intuitive workflow, and allow using enter for both search initiation and submitting results for autofill.

@erayd
Copy link
Contributor

erayd commented Feb 27, 2018

Or an alternative approach could be:

  • If the search box is empty, enter autofills the first entry.
  • If the search box is not empty, enter runs the search, and shifts focus to the first result (so that pressing enter a second time will autofill it).

@maximbaz
Copy link
Member

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.

@erayd
Copy link
Contributor

erayd commented Feb 27, 2018

But I'm asking myself, why would I want to search for a password if browserpass found some candidates?

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.

e.g. I could type a search term, accidentally hit Enter twice and unintentionally leak wrong credentials to the website.

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?

  • Initial focus is on the search box.
  • If enter is pressed, run the search (if the text box is not empty), then change the focus to the first result.

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.

@maximbaz
Copy link
Member

For the first point I created #211 - real-time filtering of already discovered list of matches.

If #211 is done, do you see benefits in your approach comparing to what I described?

@madduck
Copy link

madduck commented Feb 27, 2018

The search should happen incrementally and not require Enter in the first place, I'd say…

@erayd
Copy link
Contributor

erayd commented Feb 27, 2018

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:

  • Needing to manually hunt for something in a huge list of results (real-time filtering would help this a lot)
  • Needing to use the vertical arrow keys (on many laptop keyboards, mine included, these are so small / close together as to be a significant usability issue)
  • Needing to use the mouse at all.

@maximbaz
Copy link
Member

The search should happen incrementally and not require Enter in the first place, I'd say…

I mentioned this in #211:

I tried that at some point, it sounds cool but in reality it was a weird experience, I have hundreds of passwords and typing one letter changes the results list in a very unexpected way, especially when you press Backspace and the list suddenly grows with 20 new records, or when you clear the search box to type a completely new domain and the list fills up with all of your 100 passwords...

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.

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?

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.

Basically the main things I want to avoid are...

I believe these two points cover all of your requirements:

☑ Filtering will be in real-time (and much faster than search, as I mentioned)
☑ Filtering will only process the list of matched domains, not all passwords in so the list of results is smaller by definition. If you are on github.com and you have entries personal/github.com and work/github.com, filtering for wo will never add wordspace.com to your list, it will only operate on github.com entries.

I suggest we move further discussion on filtering in #211, so that it's easier to find in the future.

@maximbaz
Copy link
Member

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:

  1. Click on browserpass icon, there are some matches for the current domain, input box is in filter mode.
  2. Optionally type something, this filters the list in real-time.
  3. Hit Enter and the top result is submitted.

Thoughts?

@erayd
Copy link
Contributor

erayd commented Feb 27, 2018

@maximbaz

  1. Click on browserpass icon, there are some matches for the current domain, input box is in filter mode.
  2. Optionally type something, this filters the list in real-time.
  3. Hit Enter and the top result is submitted.

This sounds perfect. I like it!

@maximbaz
Copy link
Member

Now we only need to find a brave person to implement the filtering 😉 😄

@madduck
Copy link

madduck commented Feb 27, 2018

@mazimbaz That is exactly what I had in mind too. \o/

@erayd
Copy link
Contributor

erayd commented Mar 19, 2018

Looks like nobody else is tackling this one, so I will do it :-).

@maximbaz
Copy link
Member

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.

@erayd
Copy link
Contributor

erayd commented Mar 19, 2018

@maximbax I did both in one go - see #220 :-).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging a pull request may close this issue.

6 participants