Ticket #8234 (closed feature: fixed)

Opened 2 years ago

Last modified 2 years ago

Autocomplete: Automatic race-condition handling for custom sources

Reported by: sexconker Owned by: sexconker
Priority: minor Milestone: 1.8.19
Component: ui.autocomplete Version: 1.8.18
Keywords: Cc:
Blocking: Blocked by:

Description

I'm testing with JQuery 1.7.2 and JQueryUI 1.9m7.

I have an autocomplete that hits up page via AJAX. Regardless of the delay set, I can get a race condition to trigger, but it is easiest to get it to trigger when the delay is 0. It does not depend on whether or not autoFocus is true or false.

For example, quickly typing in "he" will show the result set matching "", or "h" or "he". Here's a screenshot of it happening. http://i.imgur.com/TKBdx.jpg

The top half of the image shows the correct result set being returned after typing in "he". The bottom half shows the incorrect result set being returned. The result set returned in the bottom half of the image is the correct result set for "h".

The request for "h" does fire off before the request for "he". http://i.imgur.com/9nLu7.jpg

The input no longer has the bug where characters are seemingly deleted. For that behavior, it seemed as if the result was setting the input's value to what it was when the old AJAX request was initiated, thus overriding any typing since that request was made.

It now seems as if the input field's value is set to what it was when the most resent result was sent (fixing the "character deletion" bug), but the incorrect (not the most recent) result set can still show.

See http://bugs.jqueryui.com/ticket/7555 and http://bugs.jqueryui.com/ticket/7926

Change History

comment:1 Changed 2 years ago by scott.gonzalez

  • Owner set to sexconker
  • Status changed from new to pending

I'm not seeing this at all. I can even see the original request get cancelled. If I remove xhr.abort() and force my requests to always result in the second request completing first, I still see the correct behavior. Please provide a reduced test case showing the problem.

comment:2 Changed 2 years ago by sexconker

  • Status changed from pending to new

See  http://waitillfixit.com/autocomplete/ .

There is an artificial delay (500 ms) inserted when the search term is 1 character long. Type in he at a normal speed and you should see the bug. The "h" results take over the "he" results. Type he slowly and it works fine.

comment:3 Changed 2 years ago by scott.gonzalez

  • Type changed from bug to feature
  • Summary changed from More Autocomplete Race Conditions to Autocomplete: Automatic race-condition handling for custom sources

Ajax doesn't matter here. You're using a custom source. Also, you shouldn't double filter your results, your server should just return the correct data...

comment:4 Changed 2 years ago by sexconker

Yes, I'm using a custom source, but I'm still feeding back into the response callback as indicated in the docs. Am I not doing it properly?

Are you able to recreate the bug or not? How is it a "new feature" request to have the result set displayed correspond to the latest request?

The server does return the correct data, this is just a trivial example based on a skeleton of our code. There are a bunch of different checks and options that our full code does, including allowing wildcards, ranges, etc.

comment:5 Changed 2 years ago by scott.gonzalez

  • Status changed from new to open

Custom sources were designed as a very low level solution. The source itself is responsible for everything: gathering data, filtering, parsing, caching, throttling (excluding typing delays), etc.

comment:6 Changed 2 years ago by Scott González

  • Status changed from open to closed
  • Resolution set to fixed

Autocomplete: Move race condition logic from ajax requests to general response handler. Fixes #8234 - Autocomplete: Automatic race-condition handling for custom sources.

Changeset: 96f9c84b7b2149c6b93ac226a52065652f218e1e

comment:7 Changed 2 years ago by Scott González

Autocomplete: Move race condition logic from ajax requests to general response handler. Fixes #8234 - Autocomplete: Automatic race-condition handling for custom sources. (cherry picked from commit 96f9c84b7b2149c6b93ac226a52065652f218e1e)

Conflicts:

tests/unit/autocomplete/autocomplete_core.js ui/jquery.ui.autocomplete.js

Changeset: d040b8f42cc28932deedddebe95473a9fd13d742

comment:8 Changed 2 years ago by scott.gonzalez

  • Version changed from git to 1.8.18
  • Milestone changed from 1.9 to 1.8.19

comment:9 Changed 2 years ago by sexconker

Thanks for the explanation. I didn't expect the race condition logic to only handle the string version of source. I've wedged in a quick fix based on that code into our custom source for one of our projects where it's a noticeable issue.

When 1.8.19 is rolled out we'll update all our projects.

Note: See TracTickets for help on using tickets.