reason found: you can call it bug by design, or unwanted side effect
proposed fix: available. described literally; no code published yet, sorry (but follows)
Pls. reopen issue
I'm reclosing this. Outstanding requests are aborted as soon as a new search is started and invalid responses are ignored (*), so I don't see how this could be happening. If you can provide a reduced test case showing the problem, feel free to let us know.
(*) my analyis based on example code like on the jqui API pages showed, that you are wrong. Each callback in its own context fires a new request, and an older request may overtake newer ones. This is the problem: a single older request which comes later overwrites in consequence the input. This happens for example while very quickly typing characters with autocomplete parameteres min=2 and delay=200.
Can I ask you to please can you leave this issue open ? Why...? Let me explain.
I know, you want to see a patch. I will deliver such a patch, and a working example but haven't the time at the moment. But the good news is, that I now could **finally** solve the issue by applying two fixes !
In my environment, I was able to fully reproduce the effect of "autoFocus randomly deletes typed characters". I found the reason and a solution in the client code.
Allow me first to explain the patch in words (bear with me; a description in words may be difficult to understand). Later (may be mid December 2012), I will publish the code, no cookie-licking, promised.
I found, that indeed my analysis was correct. that it is a race condition:
when the server's response for a previous partial search (example: "jav" <-> old response) is coming after the response of current input "java" - then the old response - the first ajax is not killed - overwrites the new one.
This ***looks*** like "autoFocus randomly deletes characters***, but it is not. Its only reason is that an older server response "overtakes" the current (last) query, and this older server response updated the input div. As you usually type an increasing number of characters, this means, that an "older" server response corresponds to **less** characters then you have typed --> resulting in the effect and issue.
I could fix this behaviour by expressly deleting _any_ pending ajax request before submitting the new subquery.
A second fix was required for the autofocus=true case: I make now sure that the current $("#input").val() is now always immediately updated from the corresponding server response - when it returns, This overwrites not the elements in the ui-list but only as said the exact response to the user's input.
I will try to apply a correct fix in the autocomplete code itself, if this is possible.