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 44 users

Issue metadata

Status: Fixed
Owner:
no longer working on chrome
Closed: Jan 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocking:
issue 224380
issue 234986
issue 244476



Sign in to add a comment

Remove ~300ms delay on tap for mobile sites (those which are not initially scaled)

Reported by jakearchibald@google.com, Jan 12 2013

Issue description

Example URL:

Steps to reproduce the problem:
Tap on a link / interactive element

What is the expected behavior?
Speeeed

What went wrong?
Currently, tapping a link is hit with a ~300ms while we work out if there's going to be a double-tab. We remove this delay if the viewport cannot be zoomed. Can we remove it in more cases?

If double tap is for zooming text to a readable size, can we assume the developer has already taken care of this if width=device-width in meta[type=viewport] and drop the feature (and the tap delay).

The web community is keen on zooming as an a11y feature http://alwaystwisted.com/post.php?s=2013-01-10-dont-do-this-in-responsive-web-development, can we retain zooming without the tap delay?

Does it occur on multiple sites: Yes

Is it a problem playing media? No

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes m25

Chrome version: 25  Channel: dev
OS Version: Jellybean
 

Comment 2 by joh...@chromium.org, Feb 21 2013

Cc: joh...@chromium.org
Cc: aelias@chromium.org yus...@chromium.org klo...@chromium.org
Labels: Feature-Input-Touch
Status: Available

Comment 4 by joh...@chromium.org, Feb 21 2013

Cc: eseidel@chromium.org rbyers@chromium.org
Labels: Stability-Performance
I'll copy my analysis from https://groups.google.com/a/google.com/d/msg/chrome-touch/c2X_Usae8Gc/06Bnw1aYZnwJ:


I was pondering this a while ago, and it seems there are various different cases to consider.

As context, I'll define some subtleties of double-tap zoom: double-tapping on a block of text should zoom in until the tapped-on text is legible. When tapping on wide paragraphs, this usually means fitting the block of text to the screen (really wide paragraphs will still be legible thanks to Text Autosizing); when tapping on narrow paragraphs, this means zooming in until each CSS px of the page is rendered using 1 DIP (density-independent pixel), and then centering the block onscreen. Note that a desktop page is usually around 980 CSS px wide, and a 10" tablet is about 1280x800 DIP (though, taking into account the increased distance they are usually held from a user's eyes, they are arguably effectively only around 1024x640 DIP).

First I'll respond to Rick's comment:
> How bad do we think it would be in practice if we send click events on first tap for double-tap? (...) I've
> heard users say they look for whitespace to double-tap anyway, and they always have the fallback of pinch.

That would be great (and I'd be keen to try eseidel's build that experiments with doing this), but try double-tap zooming on a sidebar for example - it'd be almost impossible. Empirically I already find I accidentally click links a lot with mobile browsers (some part of my hand touches the edge of the screen, or something), and whenever it happens it's really jarring (and would be confusing to novice users).

So when do we need double-tap and when can we kill it?

Disable on laptops
------------------
On laptops, text is already legible without any zooming, so a double-tap gesture is not needed at all. Chrome on Windows 8 touchscreen laptops does this already.

Disable on mobile sites (unless zoomed in)
------------------------------------------
When viewing mobile sites on phones and tablets (i.e. width=device-width, or a fixed width smaller than device-width), with default text scaling settings, again text is already legible without any zooming. So users shouldn't double-tap, and if they did it wouldn't do much* anyway, hence it seems reasonable to remove the double-tap gesture completely in this case (even on sites that allow zooming).
An exception is if the user has manually pinch-zoomed in, then it is reasonable for them to expect double-tap to zoom back out again, so perhaps we should enable double-tap (and the corresponding delay) if and only if they are currently zoomed in (which should be rare).

Preload link when viewing desktop sites on phones
-------------------------------------------------
When viewing desktop pages on phones, double-tap is essential, and we can't reasonably change the gesture. We could however start preloading the link destination (rather like we preload urls typed into the omnibox), such that after the 300ms delay, the page would take 300ms less to load. Obviously we wouldn't be able to do this for JavaScript links/handlers, as we have no way of rolling back JS actions. We could also highlight the link immediately, so the browser seems responsive and the user gets instant feedback that they have clicked the right link; if they then continue to perform a double-tap, we would fade out this highlight, showing that it was cancelled by the second tap. Similarly I also like the idea ( crbug.com/164286 ) of immediately showing e.g. checkboxes as visually ticked, and only updating the DOM (and firing events) 300ms later if there wasn't a 2nd tap.

??? when viewing desktop sites on tablets
-----------------------------------------
Landscape 10" tablets have device-width > 980px, so behave the same as laptops, and in theory don't need double-tap. But portrait 10" or 7" tablets and landscape 7" tablets are both narrower and hence do need a little bit of zooming. We could drop double-tap only on landscape 10" tablets, which might work, but could be a little bit inconsistent*. Or there might be a reasonable case to be made for dropping double-tap completely on 10" tablets (users would have to pinch zoom in portrait), but keeping it on 7" tablets. Either way we should probably look at UMA stats (and possibly a UX study) before making this kind of change...

--John

*: A slight complication is that in cases where double-tapping wouldn't otherwise do anything, Chrome for Android currently makes double-tap zoom in to 1.3x the overview zoom level. But this isn't particularly useful, so it should be fine to lose this behavior in the cases above and have double-tap consistently do nothing in those cases.
Cc: haraken@chromium.org
Is there a sample code?

Recall there is another issue when hover on iOS (http://www.nczonline.net/blog/2012/07/05/ios-has-a-hover-problem/) but it's only occurred when `display` or `visibility` is touched

Was reading a blog article at the weekend. It was optimised for mobile (meta device-width). I got to the comments, the avatars were on the left, the comments were on the right, so there was a column of whitespace below the avatar. I instinctively double-tapped on the paragraph to bring it to full width, which worked as expected.

I'm no longer convinced we can just disable double-tap on sites with width=device-width.

However, when I double tapped, I deliberately avoided tapping on an area containing a link, so maybe that can be our condition. Taps on links can remain instant, but still catch double-taps on non-full-width text.
Here's another idea that may make sense to pursue in parallel to the other ideas discussed here: add a simple mechanism to allow authors to disable double-tap/click-delay (eg. maybe as another viewport meta flag / device adaptation option).

We user-scalable=no disables zooming entirely and removes the click delay.  Disabling just double-tap has the potential to cause user confusion, but we're already in this position today.  Lots of sites use a 'fastclick' library to remove the click delay and generally disable double-tap (without affecting pinch).  But these libraries have bugs, impose performance overhead (eg. on threaded scrolling) and cause problems in scenarios where there is no click delay (eg. Chrome desktop).  Since sites are already making the decision to have this behavior, perhaps we should at least give them a simple switch to get that behavior rather than have to rely on complex/buggy libraries.
I'd rather fix the existing web than add another viewport option, but yeah, if we can't do it without breaking backwards compatibility, another option is better than FastClick.
Re #7, what was the url? If it was truly a width=device-width page, then you shouldn't really have needed to zoom in, and the only reason double-tapping did anything at all is because of the * at the bottom of #4.
Annoyingly I didn't write it down. Will post it if I remember. The text was pushed to one side of the screen because of an avatar, so there was a legitimate "zoom to paragraph width" case
I'm sure there are many mobile sites where text isn't full width. But double tap isn't "zoom to paragraph width" it's "zoom until this is legible", where legible approximately means that the zoomed text will render at 1 density-independent pixel per CSS pixel of specified font size.

(For narrow paragraphs, this is achieved purely by zooming in to the 1 DIP == 1 CSS px zoom level; for wide paragraphs this is achieved by zooming to the paragraph width, which works because Text Autosizing [wkbug.com/84186] will have pre-adjusted the computed font size so it is legible at that zoom level.)

On width=device-width sites, there may well be columns narrower than the screen, but it shouldn't be useful to zoom in on them since they are already (due to the viewport tag) being displayed at the 1 DIP == 1 CSS px zoom level.

(The above assumes a fully-sighted user whose Chrome for Android Settings > Accessibility > Text Scaling setting is set to 100%; for partially sighted users who significantly increase that setting we do need to keep double-tap as the user will have good reasons for zooming in - unless  issue 135869  makes the viewport narrower, in which case there may once again be no need to zoom in).
I stand corrected!
Project Member

Comment 14 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Webkit -Feature-Input-Touch -Stability-Performance Cr-Content Cr-UI-Touch Performance

Comment 15 by tonyg@chromium.org, Mar 13 2013

Cc: tonyg@chromium.org

Comment 16 by laforge@google.com, Mar 15 2013

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

Comment 18 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink

Comment 19 Deleted

Blocking: chromium:234986
Cc: kouhei@chromium.org
Cc: astrange@chromium.org
Blocking: chromium:244476
Blocking: chromium:224380
Note that the upcoming touch-action CSS property ( issue 241964 ) can be used to disable double-tap and hence the click delay on specific elements (as is done already today for IE10).

Comment 26 by gstr...@gmail.com, Jun 20 2013

I think browsers should support a simple page level property, so developers could disable double taps for a specified page.  If the browser knows there are no double taps, then the 300ms delay can be eliminated.  In the future, the Pointer Events W3C recommendation could fix this problem, but in the meantime, why not implement a simpler solution?  I think it would be a huge win for mobile web apps.
Re #26, if the page has user-scalable=no in the viewport tag, there is no zoom and no 300ms delay. This trick is used by mobile web apps. Does it work for you?
user-scalable=no isn't a solution. Context: responsive web apps. Even if the application is tailored for the device, it's still a usability/accessibility benefit to allow user zooming. I would not disable this to avoid the 300ms delay. They should be independent properties.
Double-tap zoom is a core gesture. Letting pages opt out independently of whether they allow pinch zoom would lead to a fragmented user experience.

Instead we should just disable it for *all* mobile sites (where viewport width <= device-width), as explained in comment 4.  This solves the problem for responsive web designs.
Owner: joh...@chromium.org
Status: Started
I've uploaded a patch which implements "Disable on mobile sites (unless zoomed in)" that I suggested in comment 6:
https://codereview.chromium.org/18850005/

Currently it'll also disable double-tap for landscape 10" tablets (as it defines mobile pages as pages whose width is <= the screen width when viewed at a 1x pageScaleFactor, i.e. when 1 DIP == 1 CSS px). It seems reasonable to try that out on dev channel for a while, and if we don't like it we can do a follow-up tweak to the tablet behavior.
See also  issue 306269  for one tentative approach for potentially removing the click delay entirely.
Summary: Remove ~300ms delay on tap for mobile sites (those which are not initially scaled) (was: Remove ~300ms delay on tap more agressively)
From the CL it looks like this optimization applies regardless of how we got to a page scale of about 1, right?  Some people recommend using initial-scale=1 instead of width=device-width (eg: http://www.quirksmode.org/blog/archives/2013/10/initialscale1_m.html), but it doesn't matter to this CL which mechanism is used, right?
Yup, that was the intention. There's nothing magic about width=device-width specifically, and other equivalent viewports should be treated the same (including @viewport, and even the legacy meta tags we support).
Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen
Project Member

Comment 35 by bugdroid1@chromium.org, Nov 1 2013

------------------------------------------------------------------------
r232245 | johnme@chromium.org | 2013-11-01T00:35:17.379866Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java?r1=232245&r2=232244&pathrev=232245
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java?r1=232245&r2=232244&pathrev=232245
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/java/src/org/chromium/content/browser/ContentViewGestureHandler.java?r1=232245&r2=232244&pathrev=232245
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/javatests/src/org/chromium/content/browser/ContentViewGestureHandlerTest.java?r1=232245&r2=232244&pathrev=232245

Disable double tap zoom on mobile sites, to remove 300ms click delay

This patch disables double tap zoom on pages that have a
width=device-width or narrower viewport (indicating that this is a
mobile-optimized or responsive website).

Double tap zoom continues to be disabled for pages that disallow the
user from zooming (even if they don't have a device-width or narrower
viewport).

This causes very noticeable performance benefits: links, buttons,
checkboxes, etc respond within around 10ms instead of 300ms.
Tested this on: http://jsbin.com/ixibol/6

Users shouldn't miss the double-tap gesture in the affected
situations, as double-tap means "zoom until tapped content is legible",
and in all the cases above the content was already legible (already
displayed at 1 or more DIPs per CSS pixel), so double tap zoom didn't
make sense and didn't do much.

BUG= 169642 
NOTRY=true

Review URL: https://codereview.chromium.org/18850005
------------------------------------------------------------------------

Comment 36 by janx@chromium.org, Nov 1 2013

Cc: janx@chromium.org
Finally! Thank you John :)

Comment 37 by vli@chromium.org, Nov 19 2013

Labels: Hotlist-DevRel
It seems to been fixed on Chrome 32.
Status: Fixed
Yes, this was fixed by https://codereview.chromium.org/18850005.

I've filed follow up  issue 328863  and comment http://crbug.com/240959#c19 to track two remaining ways to reduce this delay when viewing desktop sites on Android (as desktop sites aren't affected by this patch).

See also  issue 306269  for a radical alternative approach towards removing the delay when viewing desktop sites.
Labels: -Cr-Blink Cr-Blink-Input M-32

Sign in to add a comment