1060750 - Search completion of autocomplete XUL can be uncorrelated

Status: NEW

(Toolkit :: Autocomplete, defect, P5)

Description

[Julian Viereck]

Attachment: test_autocomplete_bug.xul

With the current design of the nsAutoCompleteController, it is possible to get unrelated search completions. E.g. image the following completion scenario:

- the input "re"  gets completed to "Result"
- the input "ret" gets completed to "Retire"

in certain circumstances, the input of the autocomplete widget might show:

  ret >> Result

Note that this completion is wrong, as "ret" should not complete to "Result".

Ways to achieve such a situation are either (as far as I can think of them):
a) the search provider triggers an async search for the call to |startSearch| but ignores the call to |stopSearch| and therefore does not stop the search. This causes the search eventually to arrive and the search results might be uncorrelated to the current input field's value

b) the search results might come back out of order. Assume there are two search results A and B, where A is triggered before B. But B might arrive before A, which can cause the same problematic scenario from above.

For the case a) I've created a test case, that you can find enclosed. The test case has a bunch of comments, so I hope it is easy to understand what is going on.

There are two possible fixes I see for this:

1) complete the value only if the search result and the input value are related (e.g. "Result" is not related to "ret" and therefore the completion should not happen)
2) associate a searchId with each triggered search. If the last triggered search is b, but onSearchComplete is called with the results for a, then ignore the search results.

Personally, I think 2) is the better solution here. 1) only "masks" the real problem.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Julian Viereck from comment #0)
> a) the search provider triggers an async search for the call to
> |startSearch| but ignores the call to |stopSearch| and therefore does not
> stop the search. This causes the search eventually to arrive and the search
> results might be uncorrelated to the current input field's value

yes. this is a bug of the search provider, though it would be nice to have protection in the controller.

> b) the search results might come back out of order. Assume there are two
> search results A and B, where A is triggered before B. But B might arrive
> before A, which can cause the same problematic scenario from above.

this is possible indeed, the controller doesn't know why the search provider returned that result for ret, but it did, so it must be a valid match. It's possible for example it matched a tag (in the awesomebar case) so we and up with fancy "dog >> cat" cases. That's why we always tried to avoid doing in-the-middle autocompletion (that's how this >> thing is called)

> Personally, I think 2) is the better solution here. 1) only "masks" the real
> problem.

I don't think 2 is going to fix this for good exactly cause the search provider can return a result for whatever reason and thus you can still end up with fancy in-the-middle completions. Moreover even if the results come at different times they might still be good matches.

Maybe we should just check if the target string contains the original search string and not trust the search provider?
Or add an attribute that allows to opt-out of in-the-middle completion.

I don't see an alternative clean solution, Paolo is right that the toolkit autocomplete is too generic at this point and we should split out a dedicated implementation for the urlbar, that for example won't even provide in-the-middle completion at all...