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.