5 minutes ago when I tried to open Meta Stack Overflow I got a message like below

Screenshot of error page

Then again I tried with Stack Overflow; the same thing happened. Being a member around 1+ years, and this is first time I'm getting this message. May I know more details about it.


Okay, from @shog9 's answer, I understood the cause of problem. let me clarify it.

When I tried to search for a user in user filter unknowing first I pressed enter key twice and found 2 loading symbol; weird. Then out of curiousity I long pressed and the screen was loading with bunch of loading symbols like below

enter image description here

Now my eyes got opened and I looked into the no.of requests in the network tab of dev tools.

enter image description here

This whole thing I tried in my system, then my colleague next to me told "Stack Overflow is down"(showing the above message).

Again as I tried in my system, I too got the above message.

Sorry for making fun/mistake that I have done, but I think it as bug, we should not allow enter key to be pressed in users filter similar to tag filters.

  • 4
    Well, there are about 60 users at your current IP address; someone could have been spamming. Are you on a particularly shared network?
    – Ry-
    Mar 5, 2014 at 4:55
  • @minitech Yes, I'm connected to a shared network. let me check with my colleagues.
    – Praveen
    Mar 5, 2014 at 4:59
  • 6
    I just visited the user page and tried this. Whether it's enough to trigger a temporary flood block or not, it does seem like undesirable behavior to continuously generate requests on enter key auto-repeat key strokes. Perhaps the client-side can be modified to not send a new request if the filter text hasn't changed since the last one was sent. (Reproduced in Chrome, Windows 7)
    – Jason C
    Mar 5, 2014 at 5:21
  • 1
    Reproduced in Firefox Aurora 29.02a; I can produce an enormous amount of requests just by holding enter. Mar 5, 2014 at 5:21
  • Related declined report: meta.stackexchange.com/questions/90254/…. Mar 5, 2014 at 8:20
  • @Oded "we should not allow enter key to be pressed in users filter similar to tag filters" - sounds more like a feature request if not a bug. Going to edit the post, but of course it can be declined as well. :) Mar 5, 2014 at 9:52
  • BTW, the same thing happens with the tag filter box too, it's just not so obvious because there's no spinner. Mar 10, 2014 at 12:22

2 Answers 2


You've made several hundred requests to /users/filter in the past 20 minutes - what's up with that?

...Actually, there are rather a lot of duplicate requests for various pages / filters from your account. You might want to make sure you don't have any dodgy extensions installed.

  • 14
    Clearly a cat falling asleep on the keyboard.
    – Tim Stone
    Mar 5, 2014 at 5:06
  • Actually I made this mistake by long pressing the enter key, now I have updated my question.
    – Praveen
    Mar 5, 2014 at 5:18
  • 6
    The trick is to have just the right amount of coffee when typing. Not too little, and definitely not too much ;-)
    – Shog9
    Mar 5, 2014 at 5:20

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 jQuery.fn.typeWatch. Here, 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.

(The 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .