ACP Members Search needs a delay
Submitted PeterUK, Aug 06 2012 12:50 PM | Last updated Oct 11 2012 01:35 PM
Not 100% sure if this is a bug or a small feature request, you can often get the incorrect results returned from it though so it can cause what I would consider a bug to occur. It also causes a lot of unnecessary AJAX requests to fire.
When searching in the AJAX-powered box in the ACP for members, (the one on the actual members page), results can often get confused, because instead of waiting a short time (say, 300ms) before firing off the AJAX query, the search does it immediately, this can cause a number of unwanted behaviours, especially if you're still typing the name when this happens, which I have working test cases for.
1) Resources. Granted, this isn't a huge one but say for example I type the string "rainy" into the box, a query is fired off immediately for "rain" and then it's fired off for "rainy" too, before the first result has even been received. There's 2 AJAX queries there when one was fine. Here's an example of what was fired off all at once when I typed "thisisareallylongstring":
2) Less finely-grained results. This one is quite hard to reproduce, but it does happen occasionally. Typing a word such as "testing" into the box, sometimes results in a query being fired off to look for "test" and then "testin" but sometimes the last characters, or in my experience, even 3-4 characters are not fired off, this means that while you have "testing" in the box, your results may be showing a much larger set, say the matches for "testin" instead of "testing". Not a great example but if what you're searching for would be really generic without the last few characters, and especially if you have a large amount of members, this does make a difference.
3) Incorrect results. Because of how the requests are fired off, you can end up with incorrect results. I have a good example of this. Here I searched for "thisismy". You can see that 3 AJAX requests were fired off, one for "thisi", one for "thisism" and one for "thisismy". These were all fired at pretty much the same time since they differ by only one or two characters. What actually happened here though is that the query for "thisi" took longest to execute (which is completely understandable as it's less refined and thus working with a larger result set than the others [apologies for the long load times shown here, I'm working on a small dev server with a huge DB, I have also had this happen on production]), this means the callback function executed last and thus the result set for "thisi" is being displayed, despite the AJAX request successfully being made for "thisismy", the actual search term.
All three issues can be resolved by waiting a few hundred milliseconds to make sure the user has stopped typing before trying to do the lookup.
When searching in the AJAX-powered box in the ACP for members, (the one on the actual members page), results can often get confused, because instead of waiting a short time (say, 300ms) before firing off the AJAX query, the search does it immediately, this can cause a number of unwanted behaviours, especially if you're still typing the name when this happens, which I have working test cases for.
1) Resources. Granted, this isn't a huge one but say for example I type the string "rainy" into the box, a query is fired off immediately for "rain" and then it's fired off for "rainy" too, before the first result has even been received. There's 2 AJAX queries there when one was fine. Here's an example of what was fired off all at once when I typed "thisisareallylongstring":
2) Less finely-grained results. This one is quite hard to reproduce, but it does happen occasionally. Typing a word such as "testing" into the box, sometimes results in a query being fired off to look for "test" and then "testin" but sometimes the last characters, or in my experience, even 3-4 characters are not fired off, this means that while you have "testing" in the box, your results may be showing a much larger set, say the matches for "testin" instead of "testing". Not a great example but if what you're searching for would be really generic without the last few characters, and especially if you have a large amount of members, this does make a difference.
3) Incorrect results. Because of how the requests are fired off, you can end up with incorrect results. I have a good example of this. Here I searched for "thisismy". You can see that 3 AJAX requests were fired off, one for "thisi", one for "thisism" and one for "thisismy". These were all fired at pretty much the same time since they differ by only one or two characters. What actually happened here though is that the query for "thisi" took longest to execute (which is completely understandable as it's less refined and thus working with a larger result set than the others [apologies for the long load times shown here, I'm working on a small dev server with a huge DB, I have also had this happen on production]), this means the callback function executed last and thus the result set for "thisi" is being displayed, despite the AJAX request successfully being made for "thisismy", the actual search term.
All three issues can be resolved by waiting a few hundred milliseconds to make sure the user has stopped typing before trying to do the lookup.
Attached Files
| Status: | Fixed |
| Version: | 3.3.3 |
| Fixed In: | 3.4.0 |
5 Comments
I thought it didn't actually cancel the request as far as the server was concerned though? It just cancelled the AJAX call completely from the browser.
Anyway, that's done by assigning the AJAX call to a variable and calling a method to cancel it later.
-
-
Updating Status to: Fixed
It only has a 300 millisecond delay right now, but it won't fire off requests if you are still typing.