-
Notifications
You must be signed in to change notification settings - Fork 80
Conversation
If there are search results present: * Typing in the search field will filter the results * Pressing <enter> will autofill the first entry * Pressing <enter> when there are no matching entries will run a normal search If there are search results present, no filter has been entered, and '\' is pressed: * All search results are cleared, as is the search input box * Pressing <enter> will run a normal search
Awesome stuff! My initial thoughts:
|
No problem - I'll add this.
Chrome doesn't appear to fire the
I strongly dislike this idea. The outcome of fuzzy searches tend to be non-obvious, and when I'm wanting to quickly filter a list, I need it to be predictable. IMO, fuzzy searches belong in the main search feature, not in the filter. The way it works now is substring matching for each word in the filter, separated by either whitespace or /. Is there a reason this is undesirable? I'm struggling to understand how fuzzy searching is useful in a quick-filter. |
Never mind - |
My experience is a lot different with fuzzy search, I find it very useful - also, when done properly, typing "work" should find the "work" entry as the top one, so you would not experience any difference comparing to the substring implementation. Try searching for full substrings in the domain search in v2.0.12, it is fuzzy by default, but nevertheless searching for substrings should put the most expected results on top. However when you get used to typing "wk", you will be pleased that it works too 🙂 However I realize that perhaps a good fuzzy search is not easy to implement and probably requires some dependency to be working acceptably well. So, a substring search is definitely preferred over a bad-working fuzzy search, but a good-working fuzzy search is preferred over the substring search 🙂 And if you are still not convinced, I'm fine with implementing a configuration option, whether filtering should be fuzzy or not. In that case, fuzzy filter and configuration option don't even have to be part of this PR. |
Do you have a library to recommend for this, that you would be happy to have included in the extension?
If you're happy with a config option, then I have no problem with the filtering being fuzzy, even by default. Just so long as I can turn the fuzzy stuff off :-). |
I'll try to test some libraries later today 👍 |
I'm using this PR and will be publishing new findings as I find something:
|
This is deliberate - if you filter out all results (i.e. to make the result list empty), it switches to regular search mode. That's why the hint vanishes. Can you explain what the desired behavior should be instead? Typo fixing - good catch. Need to think about how to resolve that one. I've swiched to fuzzy search using fuse.js - does how I've implemented it fit what you were expecting? |
OK, I've sorted the typo thing. Is that now working as you expected it to work? |
Aaaah, I see - no, keep it like this, very useful indeed. I just didn't realize that it switches to the search mode, I thought it is still in the filter mode 🙂 I'll test the fuzzy search later today 👍 |
Regarding making fuzzy filter configurable, there is already an option for fuzzy search, I'm wondering if it makes sense to reuse that same option for fuzzy filtering, or introduce a new option. Is it possible that a user would like to disable fuzzy search, but enable fuzzy filtering, or the other way around? Consider that it is also not obvious for people unfamiliar with the code to understand what's the difference between option "Fuzzy search" and "Fuzzy filter". What do you recommend? |
I found that making the filter a little more strict was enough that I was happy with fuzzy filtering as the sole option. So I would be happy to leave it as-is, and not worry about substring matching. If you think that it would be better to include both filter methods, then yes - using the existing option for fuzzy search seems like a good idea. |
OK, let's keep the fuzzy filtering as the sole option for now. I'm only unhappy with the library, I saw people complain about it, and now I see why:
I'm reviewing a few options now, what do you think about this library? https://github.com/farzher/fuzzysort If we choose it, let's disallow typos to make it strict (i.e. I haven't tested it myself yet in much details, but the demo seems quite good. Also this library is maintained now (contrary to some other existing libraries), which I like. |
I see what you mean - the behavior in your example is horrible! I'll take a look at the one you're suggesting now, hang on. |
That library seems to be overly strict with filtering on patterns that aren't at the start of a word. For example, |
Hmm this is not happening on their demo page at least... |
It happens as soon as you set a strictness threshold. Looks like it might be OK with no threshold set though - have just commited it so you can have a look. What do you think? |
I might need to do an iterated version; seems it can't handle multi-word searches. |
Could you please clarify how / where to reproduce that, if it's still an issue? I've just pushed a commit that fixes the type, but I would like to test to ensure that solved the issue. |
I didn't see when exactly that happened, but I think you most probably did fix it with the last commit. I cleared all the errors and will be testing the code in its latest stage, if any errors appear I'll compose the repro steps. |
Sounds good - thanks :-). |
chrome/script.browserify.js
Outdated
|
||
function searchKeyHandler(e) { | ||
// switch to search mode if '\' is pressed and no filter text has been entered | ||
if (e.code == "Backspace" && logins && logins.length > 0 && (!e.target.value.length || e.target.value == domain)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I think
&& logins
is not needed anymore since it can never be null -
switch to search mode if '\' is pressed
- needs to beBackspace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
chrome/script.browserify.js
Outdated
if (!this.s.value.length) { | ||
return; | ||
} | ||
if (fillOnSubmit && logins && logins.length > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think && logins
is not needed anymore since it can never be null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
chrome/script.browserify.js
Outdated
logins = response; | ||
logins = resultLogins = response ? response : []; | ||
document.getElementById("filter-search").textContent = domain; | ||
fillOnSubmit = useFillOnSubmit && logins && logins.length > 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
&& logins
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -222,14 +298,16 @@ function keyHandler(e) { | |||
switchFocus("div.entry:first-child > .login", "nextElementSibling"); | |||
break; | |||
case "c": | |||
if (e.ctrlKey) { | |||
if (e.target.id != "search-field" && e.ctrlKey) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
both copy
shortcuts seem to not work for me anymore, do they work for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Investigating...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These seem to be working for me. Perhaps fixed by one of the other commits?
Are you still having issues, or are they working for you now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Emm they actually don't even work for me in release version... okay, nevermind, I'll deal with them separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thought - is the item actually selected when you use the copy shortcuts? I did change the behavior so that they did not run when the search box was selected, because they conflicted with entering filter text (i.e. typing a capital C resulted in a copy-username-and-close behavior, which is obviously undesirable). That's what the target.id
check is for.
chrome/script.browserify.js
Outdated
function filterLogins(e) { | ||
// remove executed search from input field | ||
if (!fillOnSubmit && e.target.value.indexOf(domain) === 0) { | ||
e.target.value = e.target.value.substr(domain.length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you please explain to me the purpose of this piece?
It works weirdly...:
- Open browserpass, it is in filter mode
- Press Backspace to switch to search mode
- Type "gith", press Enter
- Press Backspace, everything is cleared (difficult to fix typo - not because of this code block, but still a valid issue)
- Slowly type "gith" again, when you enter "h" of "gith" the field gets cleared again (because of this code block)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bug. Was half of a previous solution, which I have now removed.
chrome/script.browserify.js
Outdated
// switch to search mode if '\' is pressed and no filter text has been entered | ||
if (e.code == "Backspace" && logins && logins.length > 0 && (!e.target.value.length || e.target.value == domain)) { | ||
e.preventDefault(); | ||
logins = resultLogins = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
chrome/script.browserify.js
Outdated
m.redraw(); | ||
|
||
// show / hide the filter hint | ||
showFilterHint(logins && logins.length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one more place with logins &&
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
chrome/script.browserify.js
Outdated
logins = resultLogins = response ? response : []; | ||
document.getElementById("filter-search").textContent = domain; | ||
fillOnSubmit = useFillOnSubmit && logins.length > 0; | ||
if (logins && logins.length > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one more place with logins &&
... sorry 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Yes. It will switch to filter mode if the search returns one or more results, but will stay in search mode if no results are found. If you hit backspace immediately after it switches to filter mode from a manual search, it will go back to editing the search query. |
By the way, would you like me to squash this PR into a single commit? Or leave it as-is? |
Very cool. Seems pretty solid to me, is there anything else you want to do or that is not done yet? I just tested in Firefox, there are no noticeable issues as well. Leave as it is, Github will squash when merging, but in PR we will have history of commits. |
Nope, I'm pretty happy with it now. It covers all my use-cases, and I can't currently think of anything else it ought to do that others might want from it.
Will do :-). |
Is there anything else you'd like me to do to this PR before it's ready to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome improvement, thanks a lot!
Thank you too - your input resulted in it being a lot better than it was when I initially opened the PR! |
@jangari If you want to filter your entire database using filter-while-typing, just search for |
@erayd found a tiny nitpick, not worth wasting time if the fix is not obvious, but maybe it is obvious to you? Open browserpass, it is in filter mode, start typing something until no results appear, extension switches to the search mode, but the bottom bar with "No matching passwords for github.com" appears. Ideally it should not appear, just like if you press Backspace immediately after opening browserpass. |
@maximbaz That was deliberate - i.e. "you have filtered everything, and there are no longer any results that match." I can change it though, if you think that some other behaviour would be better? |
Aaah, no, it makes total sense, it's just not instantly obvious that when you are in this state, you are at the same time in the search mode (you see, I've actually asked about this already...). Let's keep it as it is now. |
If there are search results present:
If there are search results present, no filter has been entered, and Backspace is pressed:
The reason for the Backspace feature is to allow the user to explicitly run a manual search instead of filtering, even when the automatic domain search returns matches.
If the search results are the outcome of a manual search, and no filter text has been entered, then pressing enter will not auto-fill the first entry, but will instead re-run the search. This is to prevent the user accidentally filling a login form by pressing enter twice when running a manual search.
This PR closes #40 and #211.