jQuery Forum

First a little background, I understand the pattern of creating an "extension" to modify all autocomplete functionality.  For this implementation I want to isolate the changes to a new widget so that it can used in parallel with a "standard" autocomplete widget.

This topic may apply outside of autocomplete, but uses autocomplete as an example since I know the condition exists there.

$.ui.autocomplete _create attaches event handlers using a hardcoded namespace of "autocomplete".  When it is destroyed, it relies on $.Widget.prototype.destroy() to unbind these.  This works fine since the base implementation unbinds everything which is namespaced under the widget name.  Specifically it uses this:

However, this all breaks down once you use $.ui.autocomplete as the base for your own widget:

Line 8 actually leaves artifacts behind.  Here is why:

The obvious solution seems to be to update autocomplete to use this.widgetName as the namespace for all attached events.  However, this means all events would be attached under "myAutocomplete" when using the extending widget and I don't know how else this will impact other things through the remainder of the autocomplete plugin.

Alternatively, autocomplete can be made to be responsible for unbinding events using the explicit "autocomplete" namespace.  However, this seems to devalue the routine set up by $.Widget.destroy.

Again, I do not know if this condition exists within other jquery ui plugins or not.

This seems like something that should be patched, but I'm interested in other thoughts before logging it as a bug...  Maybe there is some "reason" for this which I am overlooking?

The problem is visible in the "remote datasource" demo for autocomplete.

Reproduction:

1. Type in 'sp', wait for results

2. Press backspace, results go away as intended.

3. Type 'p' (field now reads 'sp')

4. Note, results do not come back.

Granted, you can press the down arrow to get the list, but that is not immediately obvious to the average user.  I went into the code see if i could easily get around this, and have not found a way.  The problem originates from this code:

The timeout method only executes search() if the current match does not match the previously searched term.  Unfortunately, the only way the suggestions appear is if search() is executed.

This becomes a problem when you drop below the minimum number of characters and then return to your previous search term.

Seems like a distinct bug to me, and hopefully it will be addressed in the next release.  In the mean time, any information anybody has on a patch (short of modifying the autcomplete widget source) would be greatly appreciated!

Thanks!

As I type, the search query gets more specific, so it takes less time for the server respond.  As a consequence, it is possible for the old response to arrive after the most recent one.  Obviously, this is producing undesirable effects.

I'm a little frustrated that the plugin doesn't have a way to manage this.  To me, it seems that it makes the "basic" remote data implementation unreliable in most real-world situations.  It also seems as though this would be a common problem, but I've found very little literature on it.

I've found that autocomplete is a relatively new addtion to jQuery UI, so I've put the frustration aside and started my own widget which extends autocomplete to solve for three things: 1) race conditions; 2) animated open/close; 3) caching.

The nature of this post is two-fold.  Not only to share information I've gathered on the topic of race conditions with others who might be having the same trouble, but to (hopefully) gain some insight to how other people are solving for this.

The first piece of this puzzle was that $.ajax() (and related methods) return an XMLHTTPRequest instance.  As described at stackoverflow.com, this grants us the ability to use XMLHTTPRequest.abort() method.  So I just keep a handle to the XMLHTTPRequest instance, and if it exists, call abort() before the next request is made.

Using a firebug, I could see that the requests were being aborted as expected and the symptoms of the race-condition ceased.  So far, so good... then I got to IE.  Not so much.

In IE, I was seeing run-time errors.  The odd thing is that the run-time errors seemed to be coming from deep within jQuery UI, rather than my code yet commenting out the abort() avoided the run-times.  After scratching my head for a while, I used the following simplified code to shed some light on the situation:

In Firefox and Chrome, behavior is as expected - no alert box.  However, in IE6 and IE8 (IE7 untested at this time), the success handler still fires!  As it turns out, the run-time errors were because the response was undefined as it got passed through my success code path.  My next thought was, "maybe I can just evaluate textStatus".  Unfortunately, it turns out (as seen in the alert box) it contains the string "success".

My next course of action will be to evaluate the contents of data before passing it through to the next method, and I believe that will fix the problem.  However, I am very interested in hearing thoughts from others on this.  

Is there a better way to handle this sort of thing?