New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 11 users

Issue metadata

Status: Fixed
Closed: Oct 2012
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Sign in to add a comment

Fixed viewport sites do not need a 300ms click delay.

Project Member Reported by, Jun 18 2012

Issue description

tl;dr: the only reason to delay clicks by 300ms is to recognize double taps for zooming. In cases where zooming is disabled by the viewport, we should not have this delay.

Chrome Version: Chrome Beta
Application Version (from "Chrome Settings > About Chrome"): 
URLs (if applicable):

Device: Galaxy Nexus, Transformer Prime

Behavior in Android Browser (if applicable): same

Steps to reproduce:
1. Create a page with a fixed viewport (initial-scale=1,minimum-scale=1,maximum-scale=1 set)
2. Add a click handler to some element in that page
3. Load that page
4. See what happens...

Expected result:
There should be no 300ms delay in this case since the viewport is fixed, and doubletap does nothing.

Actual result:
The same delay persists for no reason.

By fixing this we can immediately give fixed viewport sites a 300ms boost!

Comment 1 by, Jun 19 2012

Thanks for the demo. There is a delay. But it is not caused by the double tap 300ms.

Here is how the message flows. 

. touch event is detected in the browser process
. touch event is received in the render process and sent to JS
. unhandled touch event is sent back to the browser process
. the gesture detector in the browser process generates the gesture event, like tap
. tap event is received in the render process and translated to mouse move/down/up event
. webkit generates the click event and sent to JS

That is why there is a delay between JS gets touchend and click. It is not because the double tap delay.
The gesture layer does appear to be responsible for the delay.  The problem is that the browser treats single taps and double taps differently.  This is the same for iOS Safari.

When a user taps, two gesture recognizers are in play, the single tap recognizer which results in mousedown/mouseup/click, and the double tap recognizer, which triggers zooming.  To avoid generating click events when a user tries zooming in on a clickable element, there is a requirement that the double tap recognizer must fail for the single tap recognizer to proceed.

This makes complete sense on a scalable page.  It breaks down on mobile "app"-style pages which disable scaling.  On these pages, a double tap has no effect but is still being listened for, causing click delays.

The fix would be to check if viewport scaling is disabled and if it is, remove the double click gesture listener via onDoubleTapListener(null), either on page load or whenever the value changes.

Devils advocate, though, users may not necessarily know that the viewport doesn't scale and accidentally click when they are trying to zoom.

On a side note, I've noticed on iOS that if you tap and hold for at least ~130ms, their double click recognizer gets cancelled causing the tap highlight to appear.  This results in about a 15ms gap between touchend and click.  Is there something similar in place on Android?
On Android, the show highlight is 180ms from touch down. But the framework doesn't cancel the double tap. In this case, Chrome can handle singleTap immediately to avoid the delay.
Testing in Android emulators, in Android 2.3 Browser, I get the 300ms delay if I hold for under 200ms.  After 200ms the delay goes away.  On Android 4.0.3 Browser, I don't see the delay at all with my fixed viewport demo.  It looks like a fix was applied to the Android Browser or WebView to correct for this issue.  The same could likely be reused.

Measuring with
Labels: Type-Bug Area-WebKit Feature-Touch
Status: Available
Labels: -Pri-1 Pri-2

Comment 7 by, Aug 15 2012

Re #1: are you saying this is the case only for pages that have zooming disabled?  If double-tap-to-zoom is disabled, then the click event must be delayed until the GR knows it's not a double-tap, right?  This is what is a major pain for app authors to work around.

Comment 8 by, Aug 15 2012

I'm almost certain that the statement in #1 is incorrect (at least for the current build 18.0.1025.166 which I'm testing on my Galaxy Nexus).

In particular, if it's true that we're sending the click event as soon as possible (rather than delaying to see if it's a double-tap), then double-tapping a button (or other element with a click handler) should activate it.  In my tests it does not (test page from agrieve@ here:

I've heard this is a major pain for mobile web app developers in practice - they're all doing hacky things to try to get fast-click buttons (and it never quite works properly).  But they all generally have zooming disabled anyway.  PLEASE can we fix this?

Comment 9 by, Aug 15 2012

Status: Assigned
Right, I don't think we have the special treatment for pages that disable zoom yet.  Yusuf has been working on gesture events, assigning to him.
For both zoom enabled and disabled page, the sequence in #1 is executed. I thought we do, but it seems that we don't have it in m18, that we can send the tap to the render when we get singleTap from the gesture detector if zoom is disabled. Otherwise we have to wait for singleTapConfirmed. The logic described here is how it works in the Android browser from 3.0 and above.

My point is that there is still a slight delay between touchend and click.
Labels: Mstone-18
Just caught up on #1 and #10. Might be worthwhile evaluating this for the upcoming update on m/m18 - given this may help mobile web sites immensely in the short term?  

We should also make sure the change works when "Accessibility > Force Enable zoom" is turned on (overriding the zoom disable set by the page).

Can we evaluate this for a possible inclusion on m/m18?

Comment 12 by, Aug 16 2012

Yes, I think it should be a small change that's reasonable to include in M18.
ya ya ya! This would definitely be blog post worthy if it gets fixed.
Re #10, on an emulator, Android 4 Browser is geting about a 60ms delay between touchend and mousedown.  The Chromium solution would be about the same?  While not instant, user's really shouldn't perceive the delay and I'm happy with the result.
What does a 60ms delay on the emulator translate to on a device? 
60ms delay is due to how events generated. It is possible that devices are faster than the emulator. Sorry I haven't used the emulator for a long time. This is based on the last time I used emulator which is probably couple of years ago.

Chromium may have a slightly longer delay as there are more thread/process hopping.

In general, I won't expect it to be too long, definitely less than 100ms, unless the critical thread is doing something else and the events have to be processed in the order they arrived.
Labels: -Mstone-18 Mstone-24

Comment 18 by, Sep 26 2012

Based on the label change, I'm guessing that this didn't get fixed for m18? When is m24 scheduled to go out for clank?
I believe the change went to m18. But we have refactored touch handling in the master, so it needs extra work instead of cherrypick to make it happen for m24.

Comment 20 by, Sep 26 2012

Yes! I've verified that it's out with the latest public version of Chrome for Android :) Great stuff!
Labels: ReleaseBlock-Beta
Project Member

Comment 22 by, Oct 22 2012

The following revision refers to this bug:

r163445 | | 2012-10-22T23:52:12.387881Z

Changed paths:

Do not wait for the double tap timeout on pages with fixed page scale

We should't wait for the double tap timeout if we are on a web page
that has a fixed page scale. This patch lets us register the single
tap right away if that is the case.

BUG= 133391 

Review URL:
Status: Fixed
This now has been added to upstream and downstream for M24 as well.
Project Member

Comment 24 by, Mar 10 2013

Labels: -Area-WebKit -Feature-Touch -Mstone-24 Cr-Content Cr-UI-Input-Touch M-24

Comment 25 by, Mar 15 2013

Labels: -Cr-UI-Input-Touch Cr-UI-Touch

Comment 26 by, Mar 15 2013

Labels: -Cr-UI-Touch Cr-UI-Input-Touch
Labels: -Cr-UI-Input-Touch Cr-UI-Input-Touch-Screen
Project Member

Comment 28 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen

Sign in to add a comment