Suppressing the 300ms click delay

By default, if you tap on a touchscreen it takes about 300ms before a click event fires. It’s possible to remove this delay, but it’s complicated. I investigated it.

The reason for the delay is double-tap. Once your finger releases the screen, the OS and browser cannot be sure yet if you’re done with your touch action, or if a second tap will follow, which would make the action a double tap (which causes a zoom). The only way to be sure that the action is a single tap is waiting a little while, giving you the chance to make the second tap. Hence the delay.

This article gives a good overview of the problem and the solution. Unfortunately the browser compatibility information it offers is not quite right. See below.

This delay is annoying to web developers. That’s why browser vendors are looking for ways to remove it if at all possible. This is only possible if it’s unlikely that the user wants to double tap — in other words, if the user cannot zoom or is unlikely to zoom.

Now I HATE disabling zooming because it’s Evil. Not uninformed, or a bad idea. Evil. If users need to zoom on your page that’s YOUR fault for not making text and images big enough. So don’t add insult to injury.

That’s why I like the recent Chrome idea of also disabling double-tap when the page uses width=device-width. If the page is optimised for your device, it’s likely that you won’t have to zoom. And if you have to zoom anyway, pinch-zoom is still available. So this is a nice trade-off, and I’ll be watching the results of Google’s experiment with interest.

But anyway. How exactly can you suppress the 300ms click delay? Advanced web developers will immediately realise that that depends on the browser. I investigated it so you don’t have to. Findings:

That’s it, I’m afraid. Any browser not mentioned above gives no way of suppressing the delay.

Chrome weirdness

Unfortunately Chrome is acting weirdly when you set width=device-width. I test Chrome on the Galaxy S4 phone and the Nexus 7 tablet, and found that, while the delay is removed on the S4, it is not on the Nexus 7. When I tweeted this, Paul Kinlan replied that the Chrome on his Nexus 7 properly suppressed the delay. I don’t doubt that Paul saw what he reported, but it doesn’t concur with my tests.

As far as I know Opera 20 copies Chrome’s behaviour, but I did not test this extensively.

This morning I crowdsourced the tests, and found the following:

  1. Phones generally suppress the delay, although I received one S4 and one MotoX report where Chrome did not suppress it.
  2. The Nexus 7 gives mixed results; it sometimes suppresses the delay and sometimes does not. However, just before publishing this article I was notified that there are in fact two flavours of Nexus 7. It could be that the bug occurs on one but not the other. Unfortunately I don’t know which version mine is, or which version the people that replied to my test request have.
  3. I received one report of a Nexus 7 that did not suppress the delay on which Chrome crashed after doing the test 25 times. I have not been able to reproduce this.
  4. I received one report from a Galaxy Tab 2, and it did suppress the delay.

I give up. There’s clearly a bug somewhere with suppressing the delay on width=device-width, especially on Nexus 7, and I assume Google will eventually find it and fix it.

Update: Bug found and it's being fixed. That was fast.

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m around at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies: