I took a look at the code that implements this, and it turns out that, for some strange reason, it includes some code to explicitly allow rapid-fire requests when the Enter key is pressed:
var overrideBool = false;
if (evt.keyCode == 13 && this.type.toUpperCase() == "TEXT")
timerWait = 1;
overrideBool = true
This code is found in the definition of
13 is the key code for Enter, and the
overrideBool value is subsequently used to override the check that normally prevents the callback function from being run twice in a row if the contents of the field hasn't changed in between.
Presumably, this code was added for some reason, although I'm not sure what it might be. In this specific case, though, it's clearly counterproductive.
What makes it even weirder is that the key code (or the event object containing it) is never passed to the callback function, so there's no way for the callback to treat enter presses any differently from normal text changes.
timerWait = 1 line does make perfect sense — it ensures that pressing enter will trigger a new search immediately, rather than 0.5 seconds later. It's the
overrideBool = true line whose purpose eludes me.)
Anyway, if the
typeWatch() code can't or shouldn't be changed for some reason, at least the userfilter callback should be changed so that it will refuse to issue two consecutive identical AJAX requests, at least not less than, say, 0.5 seconds apart.
Ps. There's some other weird stuff in the
typeWatch() code too; for instance, I'm pretty sure the two
startWatch(this) lines in the paste and input event handlers should read
startWatch(e) instead. (As written, those events cause the
startWatch() function to look for a
keyCode property on a DOM element node, which is just silly.) Also, my DRY sense complains about the two exactly identical event handler functions, especially given that jQuery
.bind() can take a list of space-separated event names as an argument. It might be a good idea for some SE developer to give all of that code a good look-over.