Delay start of search to avoid searching for single letters

[sagamusix]

Doing searches in the web interface can be very cumbersome because the search is started immediately after the first keypress.

Steps to reproduce

1. Navigate to a folder with many files.
2. Start typing, Notice how the first typed letter of your search query will already trigger a search
3. Experience a huge slowdown which may even freeze your browser temporarily.

Expected behaviour

Search should not start immediately but wait for a tiny amount. That way, if I type "foo" into the search bar at normal typing speed, I shouldn't get a search for "f", "fo" and "foo" but just the last search. Not starting the search until about 100-300ms (may be a bit longer if only one letter has been typed so far) since the last keystroke have passed should reduce the load on the browser and server, and avoid sending unnecessary search queries.

Server configuration

ownCloud version: 10.0.7

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

Possibly related issues are https://github.com/owncloud/core/issues/17404 (About search), https://github.com/owncloud/core/issues/1666 (Sharing: username suggestions only start with 2 letters), https://github.com/owncloud/core/issues/25021 (How can I search with 2 letters?), https://github.com/owncloud/core/issues/6765 (avoid world writable folder), and https://github.com/owncloud/core/issues/17100 (Issue in contacts search).

[phil-davis]

Sounds like a good thing to do when searching for user/group name matches when sharing also. What is common industry practice for this sort of thing?

[mmattel]

https://ux.stackexchange.com/questions/38543/amount-of-time-to-determine-a-user-has-stopped-typing

snip... That really depends on the users and on what they are typing. Typing on a physical keyboard is significantly faster than on a touch device.

So the question then is what the average WPM typing speed of the average user on your system is, and then work backwards from there.

Let's say that it is 25 WPM. Typically a word is considered 5 characters long, so their rate is 120 characters per minute, or about 0.5 seconds (60 / 120). If assume that the time between keystrokes isn't even (which it isn't) and account for about a 2x variation in that (which is fairly accurate), you get to a figure of 1.0 second.

For users who type faster, say at 75 WPM, the gap that would indicate the end of typing would be only 0.3 seconds. snip...

[PVince81]

If you search in Chinese it is useful to have one character search as a single character is already a word

[PVince81]

I thought we already had a delay there with debounce

[mmattel]

point well said, same for japanese. question, there are some and I am quite sure only a very limited number of languages having that issue, what about having a language identification table and when there is a match overwriting the value to 1 character. this would be inline with the current behaviour of 4 characters but extend the functionality based on the language chosen?

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[sagamusix]

This bot seems to be a bit too trigger-happy!

[PVince81]

ok... didn't have time to investigate this but there is a high chance that this is a bug

I remember seeing that in most places we already have a delay so I wonder why this field wouldn't have one

[PVince81]

if you have time to debug, see core/search/js/search.js and see if you can pinpoint where the delay is missing