Pairing double-tap with single tap delays the single-tap response
Aliases: click delay · 300 ms delay · double-tap wait
What it is
When the same target answers both a single tap and a double tap, the recognizer cannot decide at first lift: a second tap may still arrive. It must hold the single-tap action until the inter-tap window expires. That wait is the familiar click delay / double-tap timeout on touchscreens. Every ordinary tap pays it, not only true double-taps.
Why it happens
First lift enters a pending-tap state. A second down inside the window and the distance tolerance promotes the pending tap to a double-tap and the single-tap callback never runs. An empty window then fires the single tap. Too short a window splits a slow double-tap into two singles; too long a window makes every tap feel sticky. Early mobile browsers, matching desktop dblclick, waited about 300 ms on links, and navigations felt sluggish as a result. Removing the delay is not a matter of double-tapping faster. It is a matter of putting single-tap and double-tap on different regions or control types so the recognizer need not choose on the same hit area.
Studying it
Wire both callbacks to one button, vary the inter-tap window, and log time from first lift to the single-tap callback, double-tap recognition rate, and compensatory re-taps after “nothing happened.” Also vary allowed distance between landings and whether the target sits in a scroller. Isolated laboratory controls understate the feel in lists, where the first down may already start a scroll and the window policy then fights the scroller for the pointer. The control condition is a target that never registers double-tap at all—that is the zero-delay baseline.
Where it stops holding
If double-tap lives on a photo or map surface and single tap lives on a button on top of it, the hit regions differ and the button need not wait. Accessibility “tap to confirm” or slow-click settings stretch the window to seconds; ordinary timeout numbers do not apply. Making the single-tap action a press-time preview with a lift decision does not cancel the double-tap window: as long as a double-tap is possible, irreversible navigation still waits. Voice or an external keyboard has no second knock and should not inherit the same timeout.
Applying it
- Do not register double-tap on controls that must respond instantly (links, submit, play/pause). Put double-tap on a surrounding zoomable surface.
- If one object truly needs both, let the single tap do a reversible preview (highlight, select) and leave irreversible navigation until the window ends—or give the second meaning to a long-press or a visible button instead.
- Align logs: first lift, single-tap callback, second down. If the single-tap callback lags lift by the full double-tap window, that target is still paying the tax.