Holy cow, I wrote a book!
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
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
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
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
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.