100ms timeout for query submission too brief

[Robert Schroll]

There is currently a 100 ms timeout between keypresses and query submission. This is rather short and ends up submitting many queries while the user is still typing a delay of ~300 ms would eliminate many of these submissions while still being barely noticeable.

See this thread for further discussion: https://lists.launchpad.net/ubuntu-phone/msg10361.html

[Michi Henning (michihenning)]

Re-assigning to Unity8 because it controls the timeout.

[Albert Astals Cid (aacid)]

Hmmm? How is Unity8 supposed to control this timeout?

We do nothing, all the logic i see is in src/Unity/scope.cpp from the unity-scopes-shell that has m_typingTimer that is set to 300 msec.

[Michi Henning (michihenning)]

From memory, this used to be 100 ms and was raised to 300 ms not that long ago? Maybe it's just that the scope tool isn't up to date yet? Robert, are you sure that you are really seeing 100 ms, not 300 ms?

The only source for queries is the dash or the scope tool, so unity-scopes-api is definitely not involved here.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mateo Salta (mateo-salta)]

Hi, Is there any progress on this. I'm hitting a hard stop on making my scope.

So the problem is - the scope makes several requests while typing - e.x. typing "Douglas Adams" will result in a series of multiple requests like:

Dispatching search: "ug" ""
Dispatching search: "ugl" ""
Dispatching search: "uglas" ""
Dispatching search: "uglas " ""
Dispatching search: "uglas a" ""
Dispatching search: " "uglas ad" ""
Dispatching search: "uglas adad" ""
Dispatching search: "uglas adam" ""
Dispatching search: "uglas adams" ""
Dispatching search: "duglas adams" ""
Dispatching search: "dou adams" ""
Dispatching search: "douglas adams" ""

most are irrelevant, as the api is not matching similar terms.

Also there is the problem that the api I am using limits the number of requests per hour - so I am wasting 90% of those requests.

So, we either need

- a setting to delay request
- setting for longer typing timeout
- special only send on enter (maybe special icon withing search field to indicate)

or something so we can limit the rate of requests while typing...

[Michi Henning (michihenning)]

I'm not sure whether lengthening the timeout would help all that much (although I agree that 100 ms seems unnecessarily short).

Are you responding to cancel() messages in the scope? (The shell sends a cancel for each outstanding request before it fires the next one.)

But, even with a 300 ms timeout, you still face the same problem. All it takes is a slow typist.

You could implement a longer timeout yourself inside the scope. When you get the run() call, wait a while before actually firing the request; if you get a cancel(), while that timer is still active, don't send the request. (Don't add any delay to search(); doing so will cause the request to time out for the shell.)

[Mateo Salta (mateo-salta)]

is run() in query.cpp?

Say I add `sleep(2);` (exaggerated delay to see results, later to fine tune) before `infoslist = client_.infos(query_string);` even though I still see "Dispatching search:" < is the Dispatching Search dialog part of the system (the part that sets the type rate, that then sends to the scope) or is it showing actual requests sent.

[Michi Henning (michihenning)]

You can follow what's going on by dropping some trace into your scope.

Basically, your search() method instantiates the query, and the run() method is called to send the query executing in a separate thread.

You are supposed to be quick in search(), just instantiating the query instance and not doing anything else that takes any amount of time. The shell knows that it has successfully reached your scope once your search() method completes. In turn, the scopes runtime triggers the call to run() in response to search() completing.

Now, the shell also sends a cancel() message if someone continues typing and there is still a query outstanding. So, you can track what's going on in your scope. Moreover, if you want to implement your own delay, you can do that in run(). Wait as long as you like and, in your cancel() method (which is delivered on a separate thread, so you get the callback even if run() is still executing.)

So, the strategy would be to have a delay in run() and to not actually fire the real query to the back-end if no cancel arrives for some amount of time. That way, you can basically implement your own delay without depending on the one used by the shell.

[Paweł Stołowski (stolowski)]

This was recently explored by Design team as part of various minor UI improvements and based on that research, the delay was increased to 700ms, therefore closing this bug.