Why is there sometimes a half-second delay between the click and the action?

There are places in the user interface where you may click to perform an action, but the action doesn't actually take place until a half second later. Why is there a half-second delay?

Because it's waiting to see if the user is on the way to a double-click.

Some users simply double-click everything in sight, and depending on what the single click action is, this may or may not be a problem.

If the click launches a modal dialog, then the second click is mostly harmless because the modal dialog appears on the same thread group as the window that received the stray second click. When that thread group next processes input (when the modal dialog is ready to accept input), the mouse click goes to the modal dialog, and usually it's in some harmless location so nothing happens. Often, the second click is not even at the location where the modal dialog appeared but rather remains over the original window, which is now disabled. Consequently, the click is ignored—no harm done.

But if the click launches a new process or opens a new top-level unowned window, then that second click is going to cause trouble. For example, if you clicked a link that launches a control panel, the second click goes to the launcher, and the control panel itself then appears without focus. (It can't steal focus because the user denied the focus change by interacting with the launcher window.)

A common workaround for this problem is for items that act on a single click and which fall into the second category to wait for the double-click time to see whether another click arrives. If another click arrives, then perform the operation on the second click because the user is a double-clicker. If no click arrives, then perform the operation after the double-click time elapses because the user is a single-clicker. (Filtering out accidental double-clicks is informally known as debouncing.)

The result of this is that if you're a single-clicker, then there's a half-second wait before the operation is performed.

Comments (36)
  1. nathan_works says:

    Ahh the joys of debouncing.  Unsure if you have an EE or electronics background, as that’s where I learned the term..

    I recall lab days sitting with the scope hooked up to input buttons watching how jittery the button signal could be, and learning about latching, (analog) filtering, smoothing. Never used it, but was interesting.

  2. Alexander Grigoriev says:

    That only means the particular place in the UI is mis-designed. For example, the history drop-downs in the input fields in IE. What’s the point of double click in them? It’s so strange to see them closing after a delay.

    [“Some users simply double-click everything in sight.” Doesn’t matter whether double-click has any meaning or not in any particular context. Design your UI any way you like: They will still double-click it. -Raymond]
  3. John says:

    Now if only I could figure out why Explorer randomly freezes for 5 or 10 seconds at a time…

    [Mark Russinovich teaches you how to figure that out. -Raymond]
  4. bahbar says:

    So the conclusion is, if you don’t want to wait, always double-click. Great.

  5. Pierre B. says:

    The first click itself doesn’t need debouncing, it’s the second click that needs to be ignored. Unfortunately, the nature of the resulting error means that the ignoring would have to be done at a higher level than the application due to the "authority" problem.  Maybe there should be a flag in UI element to actively ignore double-clicks and when such a double-click is performed to not act on it at all level in the UI. Only the OS (Window manager / UI toolkit / etc) can have the authority to ignore those spurious double clicks.

  6. John says:

    I read his (quite excellent) blog regularly; the problem is that my hangs don’t appear to be deterministic.  Maybe they are and I just haven’t figured it out yet.

  7. Gene says:

    Fun to know but I can’t say I’m a fan of assisting a user in doing things the wrong way, and then making them think it’s not wrong.

    But maybe that’s just me being frustrated with people who don’t want to do minimal effort to figure out how to use something and resort to blindly doing whatever it occurs to them to do.

  8. ERock says:

    Perhaps lowering the threshold for detecting double clicks (versus single clicks) should lower the delay as well?

    [I thought I wrote that in the article: “to wait for the double-click time”. The default double-click time is 1/2 second, so that’s the duration I used in the discussion. Please don’t make me bring back the nitpicker’s corner. -Raymond]
  9. Duke of New York says:

    A canonical example of this feature, I think, is the pause after clicking a desktop icon caption before it goes into editing mode.

    "Fun to know but I can’t say I’m a fan of assisting a user in doing things the wrong way"

    UI design is not a simple matter of what is technically "right." If you aren’t prepared to accommodate the user’s thought processes, you might as well stay home.

  10. Ben says:

    Hm… so is this the reason why bringing a partly hidden explorer window to topmost by clicking on the  caption bar does not immediately repaint the window contents, too? Because it seems to me that this delay for painting is bounded to the first left-button down/up action (and not a possible second button down). Which would bring up the question what is saved by not immediately posting a paint message here? There could be no “wrong” action, could it? On double-click, the window has to repaint itself nevertheless…

    [Old topic. -Raymond]
  11. Matt says:

    My mom (who is not a stupid person, she’s just somewhat computer illiterate) called one day and told me that Netscape kept crashing when she was trying to email.  This is back probably 10 years ago, on a Mac.  Every time I went home to see her, I’d check it out, and it was fine.  I finally had her show me exactly what she was doing.

    She carefully typed out her email and everything, then moved the mouse up to send, and furiously clicked on it 3-10 times in a row.  Poor Netscape completely froze up and fell over and died.

  12. Duke of New York says:

    Of course she did. Otherwise the message might get stuck in the series of tubes and clog up the whole internet.

  13. Erzengel says:

    I had a CAD teacher in middle-school, back in the Windows 98 days, who would double click the Internet Explorer icon in the quick-launch toolbar. It was much later in the school year that I finally told him (in private) he only needed to click the icon once, and he said "I wondered why it kept opening two internet windows".

    This still happens in Vista, BTW. Apparently this article does not apply to the quick-launch toolbar.

  14. spork says:

    Back in the day (win3.x) we had a custom spinner control that ate every other mouseclick. (Annoying when trying to quickly increment to the desired value.)  Removing CS_DBLCLKS from its window class fixed that. Well, that was one way to fix it…

      > Apparently this article does not apply

      > to the quick-launch toolbar.

    "QuickLaunch" is a "ToolbarWindow32" class, which does have CS_DBLCLKS.  I guess it just doesn’t distinguish between single and double clicks in its message handler…

  15. Jules says:

    Wouldn’t it just be a lot better to set a flag and have the control in question ignore the second click if two appear than start a delay after the first click before taking any action?  That way, users who don’t click twice don’t need to wait…

    Sure, if this was done, the question we’d be discussing right now is “why does a second click sometimes get ignored when I’m trying to …?”, but that seems like a much less inconvenient issue to me.

    [I addressed this in the article. “The second click goes to the launcher [which ignores it], and the control panel itself then appears without focus.” -Raymond]
  16. chrismcb says:


    "…but I can’t say I’m a fan of assisting a user in doing things the wrong way, and then making them think it’s not wrong."

    Welcome to the world of UI. Some people will insist on using that large wrench as a hammer. There isn’t much you can do, other than to make sure the app doesn’t screw up too much.

  17. wolrah says:

    @chrismcb I know where that idea comes from, but frankly I think we coddle the idiots too much. (yes I’ve been working tech support all day, how did you know?)

    My position is that allowing the right thing to happen when the user does the wrong thing isn’t the proper solution, as it just leaves them thinking they did it right, then some change down the road will make their wrong way break and they come whining.  Instead of just going with what the user means, inform them they did something wrong and how they should be doing it.

  18. Timothy Byrd says:

    (I’m almost always a lurker, but since I’m adding a comment, I wanted to say "thanks" to Raymond for all the info in his blog – even if it is "for entertainment purposes only".)

    "UI design is not a simple matter of what is technically "right." If you aren’t prepared to accommodate the user’s thought processes, you might as well stay home."

    @Duke: I’m currently dealing with this issue with my light switches of all things. They work in a very logical fashion: one tap at the top to get to last dimmer level, two taps at the top for full brightness, one tap at the bottom to turn off, and press and hold the top or bottom to set the dimmer level. The trouble is that it’s human nature to push a button instead of to tap it. (For example, I turn and hold my ignition key in my car, and I own a number of appliances that I need to hold the start button in long enough to engage.)

    So it’s natural for someone to push and hold the switch to bring the light to full brightness and then again to turn the light off. But doing that poisons it for then next person to walk into the room, who is now being trained that pushing and holding is the only way to control the light.

    I emailed tech support at the company that makes the switches. He suggested "user education" was in order. So I need to give every new visitor to my house a class in how to turn the lights on and off?

    I may be driven to writing a program that monitors the dimmer level over a serial port and then fixing things if I can detect the pathological situations.

  19. Gene says:

    @New York and chrismcb

    I do realize that one must be accomodating, but I lean towards the direction of helpfully correcting the user rather than accepting their wrong input and giving them a pat on the back for doing it.

    Mark my words, one day PCs are going to be so user friendly it’s just one button and a touch pad like the iPod.

  20. Timothy Byrd says:

    @Gene: What makes it the wrong input, other than it wasn’t what the UI designer expected (before the system was put into operation)?

    And I’m waiting for the shoe to drop – what’s the downside of PCs being as user friendly as an iPod?

  21. porter says:

    A simple UI rule from the early days was that a double click should include all the behaviour of a single click before doing its double click thing.

    Hence a double click, is a single click followed by another click in a specified time frame.

    If a single click selects an object, then a double click will similarly select an object before opening.

    No timeouts required.

  22. Jim says:

    I know the difference between a click and a double click, but sometimes (not frequently), my finger spasms, and I double click something by accident.  At those times, I really appreciate the double click swallowing.  Making things easier for "the idiots" (as the elitist few like to say) has a positive benefit for me as well.

    I always set my double click timeout quite low though – perhaps the shorter delay just isn’t noticeable enough to irritate me…

  23. J says:

    "Instead of just going with what the user means, inform them they did something wrong and how they should be doing it."

    What do you have to gain from knowing what the user wants to do, but refusing to do it?  In the case Raymond gave, you gain 500 ms and an annoyed user that probably will do it wrong the next 10 times before learning, if they learn at all.  Was it worth it?

    Nobody likes it when a computer program says "I know what you want to do, but you have to do it this other way instead."  Look at the classic Windows annoyance of dragging and dropping an icon onto the taskbar.  Because of technical limitations that Raymond has discussed previously, Windows refuses but helpfully tells you how to do what you want.  Is that how you want every program to act, especially when it’s caused by developer stubbornness instead of a technical limitation?

    (And woe to the users who get trained wrong by programs that take this approach.)

  24. Miral says:

    Now you just need to worry about those pesky triple-clickers.  (And no, this wasn’t entirely silly — they do exist.)

  25. porter says:

    I note that the double-click time has not observed Moore’s Law.

  26. Anonymous Coward says:

    At least the system should detect it if the user doesn’t do this and stop waiting half a second if the user gets it right ten times or so.

    Also, if problems like this happen, it often indicates a flaw in UI design where there is not enough consistency between the distinction between single clicks and double clicks in similar situations.

    @punishing: Actually, if you’re waiting for half a second before you start doing what you know the user wants to do, you’re punishing him also. So the question is, do you want to punish 99% of your users a little, or 1% slightly to moderately? Microsoft apparently chose the first approach in this case. I can’t say I agree with it and I’d change it if I knew how, but being part of the 99% I might be biased.

  27. Worf says:

    I had a similar issue with our old office light swiches. They were push buttons, with a red and green LED to indicate on/off (because they may control lights out of view, but people may be there).

    Alas, I kept pushing the buttons with the RED LED on (red = stop/bad, and darkness is usually bad). But no, a switch with the red LED lit means its on. Green LED means it’s off.

    I suppose you could make the case to stop before hitting the red switch…

    Then again, don’t you usually hit red switches in games to make them green so unlock the door or something?

  28. Falcon says:


    With the switches you described, what they should have done is either label the LEDs or shape them to spell out "ON" and "OFF".

  29. Leo Davidson says:

    "A simple UI rule from the early days was that a double click should include all the behaviour of a single click before doing its double click thing."

    That rule is being applied just fine here:

    – A single-click launches the application and gives it the option of taking focus.

    – A double-click launches the application and gives it the option of taking focus — i.e. all of the single click behaviour — and then takes that option away. (But it still gave the option for a split second. :))

    I don’t think it’s fair toblame the user in these cases either. If you think about it it is completely non-obvious these days which things you should click and which you should double-click. It might seem obvious to us, but we probably all started using PC GUIs back when the rules were consistent and learnt each exception (e.g. web browsers) as it came along.

    To a new user, where is the inherent logic in the buttons for launching programs requiring two clicks if they’re on the desktop and one click if they’re in the start menu or quick-launch, and why do the buttons inside of programs only require one click? Unless they are the line in a list control or the Favorite button in a browser toolbar or…

    It’s not obvious at all unless you have a deep understanding of each thing.

    It’s also not obvious how to fix it, and sometimes you can’t "debounce" because you really need distinct actions on the two events… but in cases where you can debounce, why not? It means one less exception that people have to learn. And if they double-click on those things they are *not* doing the wrong thing because those things are explicitly programmed to allow that. In fact, they’re triggering the event *faster* than those of us who single-click.

    (While wearing our their fingers a tiny bit faster. Swings & roundabouts. :-D)

  30. Tihiy says:

    Yeah, it’s the worst experience ever when VERY LOUD SOUNDS are playing and you have to wait while that sound slider will appear. Thanks god it’s fixed in Vista.

    Do you know why sound slider is in sndvol32.exe (/t), and not in stobject.dll (or systray.exe)?

  31. Karellen says:

    "But no, a switch with the red LED lit means its on. Green LED means it’s off."

    Heh. Reminds me of an interesting non-computer related i18n issue.

    Heavy machinery typically has a green and a red button. In many parts of the world, green means go, red means stop. But in others, red – because red also means "danger" and heavy machinery is dangerous when it goes – means "go", and green – because that’s the button that makes the machine safe, and green is associated with safety – means "stop".

  32. Aaron G says:

    The problem with the control panel/launcher scenario is that the launcher merely ignores the second click.  The correct behavior would be to send a strong electric shock through the mouse, pop up a large modal dialog that says "Don’t click on that icon twice!", and immediately cut the power after the dialog is canceled so that the user cannot do any further damage.  Users would learn very quickly what they should and should not double-click on.

    Of course I’m kidding.  Maybe.

  33. Duke of New York says:

    Let’s not forget about the last program based on the concept of guessing what the user wants to do and then teaching the "right" way to do it:


  34. RandomEngy says:

    So these perverse people who double-click everything are making things slower for those of us who do things correctly?

    That’s just awful.

  35. Wolf says:

    "When that thread group next processes input (when the modal dialog is ready to accept input), the mouse click goes to the modal dialog, and usually it’s in some harmless location so nothing happens."

    The mouse cursor can be configured to always jump to the default command button in a newly opened window. In this case, the second click will almost always start an action in the modal dialog. I have configured my mouse this way, and very rarely, I double-hit the mouse button by accident and immediately start some action in the new window (I still prefer this setting over the normal setting, most accidental double clicks so far havn’t too much damage (-: )

  36. Joseph Koss says:

    It is the fault of early Windows versions for training the majority of people into thinking that double-clicking isnt something exceptional.

    The end result should have been obvious. Thanks.

Comments are closed.