jQuery UI Autocomplete deletes characters in form input fields during typing
When typing in an input field where the jQuery UI Autocomplete component is active, characters have a tendancy to get deleted when autocompletion kicks in.
I think this is best explained through an example case:
User types "@Phone" in the Context field of the new action form.
Along the way, say, when the user has typed in the characters "@Pho", the autocompletion JS seems to kick in, adding the class "ui-autocomplete-loading" to the active input element. This class is soon removed, and if a suitable candidate was found in the autocomplete source array it is shown as a suggestion under the active input element. However, in that case, if the user entered any new characters in said input field in the brief period the "ui-autocomplete-loading" class was active, those characters are removed from the field. (This almost looks to be an intentional way for the JS to ensure the integrity of the autocomplete suggestion).
Thus, when the user is finished typing, the input field might read "@Phoe" instead of "@Phone" as the user intended. Ofcourse this is when the autocomplete JS kicks in again, finds out that "@Phoe" doesn't match anything in the source array, and removes the suggestion.
This is annoying as hell. Autocompletion is king, but it should not interfere if I want to spell something out myself. That is often quicker anyway.
The sad thing is that from what I have gathered this doesn't seem to be "Tracks' fault". More likely this is either a necessary consequence of the inner workings of jQuery UI Autocomplete, or a poor thought out feature.
Maybe we should ask the jQuery UI team?
Confirmed on Firefox 3.6.15/Linux, Firefox 4.0/Linux, Firefox 3.5.8/OSX, Opera 11.01/OSX and Safari 5.0.1/OSX.
I think this is best explained through an example case:
User types "@Phone" in the Context field of the new action form.
Along the way, say, when the user has typed in the characters "@Pho", the autocompletion JS seems to kick in, adding the class "ui-autocomplete-loading" to the active input element. This class is soon removed, and if a suitable candidate was found in the autocomplete source array it is shown as a suggestion under the active input element. However, in that case, if the user entered any new characters in said input field in the brief period the "ui-autocomplete-loading" class was active, those characters are removed from the field. (This almost looks to be an intentional way for the JS to ensure the integrity of the autocomplete suggestion).
Thus, when the user is finished typing, the input field might read "@Phoe" instead of "@Phone" as the user intended. Ofcourse this is when the autocomplete JS kicks in again, finds out that "@Phoe" doesn't match anything in the source array, and removes the suggestion.
This is annoying as hell. Autocompletion is king, but it should not interfere if I want to spell something out myself. That is often quicker anyway.
The sad thing is that from what I have gathered this doesn't seem to be "Tracks' fault". More likely this is either a necessary consequence of the inner workings of jQuery UI Autocomplete, or a poor thought out feature.
Maybe we should ask the jQuery UI team?
Confirmed on Firefox 3.6.15/Linux, Firefox 4.0/Linux, Firefox 3.5.8/OSX, Opera 11.01/OSX and Safari 5.0.1/OSX.
Leave a comment
on 2011-03-25 05:55 *
By lrbalt
Status changed from New to Accepted
Status changed from New to Accepted
I will increase the delay a bit. From the docs:
"The delay in milliseconds the Autocomplete waits after a keystroke to activate itself. A zero-delay makes sense for local data (more responsive), but can produce a lot of load for remote data, while being less responsive."
By default it is 300ms. Are you able to experiment with this? Otherwise I'll set it to 500...
"The delay in milliseconds the Autocomplete waits after a keystroke to activate itself. A zero-delay makes sense for local data (more responsive), but can produce a lot of load for remote data, while being less responsive."
By default it is 300ms. Are you able to experiment with this? Otherwise I'll set it to 500...
Interesting. I thought the source was a local array in this case, but I see now that we are querying the server instead. This might explain things, as it seems like it is the characters typed during the time when autocomplete is waiting for the server that gets deleted.
I'll tinker around with it and see if I can find a suitable delay, bearing in mind that server response time can vary a lot.
I'll tinker around with it and see if I can find a suitable delay, bearing in mind that server response time can vary a lot.