New Search: Cute timing bug when changing search type before page finishes loading

Cute timing bug on a sufficiently slow connection: Say you want to search for an author. Enter the search term in the new search box and hit Enter. The search page loads, the sidebar boxes load, the search results area has the little spinner. Click on "Author" while the spinner is still spinning, it changes to an author search and soon the authors appear. Wait a second... it changes back to a Works search and the results change to the Works search results.

I don't always get the author search results, but the selection does change to author when I click on it, then changes back to Works. Probably depends on exactly how far the page has got in its loading when I click it, but I can get it to display author results and then change to work results better than half the time.

This could be "solved" by disabling some page elements while waiting for the search result to come back.

So I'd have to wait for the Works search to complete and load before I could ignore it and click the Author button? Doesn't sound like a good solution, though I admit it would prevent the weirdness. Isn't there a way to cancel the pending operation as soon as it starts another one?

It's not a good solution (hence the solved in quotes), it's just one based on cost-benefit.

Okay, here's a better solution that's one I've used in similar situations. In the code, keep a variable for "searchID". It's an integer that gets passed to the server with each search request and the server just passes it back in the response and otherwise ignores it. Now, on the client side, every time you submit a search, it increments the searchID. Only results that come back for the current searchID are used, others are discarded.

This keeps the complexity fairly low, but there's several places in Tim's client code that would have to change, as well as the server code. Right now, his ajax code is just passing in a div's ID with the query. When the results come back, they simply replace the content of that div with what came from the server. There's no code to check ANYTHING there now. I'm just not sure it's worth it for the minor case of impatient users on slow connections.

The original ajax call needs to be aborted when the second one kicks off. I have code for this in jquery and prototype, Tim. Just ping me.

Yeah, I wanted to ask you. Ping me if I don't you.

Fixed.

Very nice - thank you!