Web-Facing Change PSA: no more 300ms click delay, or double-tap zoom, on mobile websites

[John Mellor]

Primary eng email

joh...@chromium.org

Summary

Previously on Android, double-tap zoom was disabled on websites which prevent the user from zooming (for example they have user-scalable=no in their meta viewport tag), but enabled on all other websites.

As of crrev.com/18850005 (landed in Chrome 32), double-tap zoom is now also disabled on all mobile or responsive websites, specifically any website whose computed viewport width (usually equal to the page width) in CSS pixels is <= the window width (usually equal to the screen width on mobile devices) in DIPs.

Motivation

To support double-tap zoom, the browser has to delay every click event sent to the webpage by 300ms, since you have to wait to find out whether they are going to tap a second time before sending the click event. This is a huge price to pay!

On mobile and responsive sites, double-tap zoom had almost no effect (as text is generally legible without zooming on mobile/responsive sites). So removing it has little downside, and in exchange, the mobile web becomes much more responsive - enjoy :-)

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

No other Blink platforms support (or plan to support) double-tap zoom. I haven't yet discussed this with the (WebKit not Blink) Chrome for iOS team, so I don't yet know whether it would be possible to add a similar heuristic there.

Demo link

Go to jsbin.com/ixibol/6, and click the link, button and checkbox label marked "Click this". Before this patch, you should observe a visible delay before the clicks take effect, and the delay calculated in JS, based on the time delta since the touch-up event, should be up to 300ms. After this patch, the delay should be imperceptible, and the calculated delay should be around 5ms (limited only by CPU speed).

If you want to preview how this will behave before Chrome for Android 32 is released to beta, visit jsbin.com/exAdATa/2 which has a "user-scalable=no" viewport, and so should already have no click delay (and no double-tap gesture).

Compatibility Risk

I believe we are the first mobile browser to use such a heuristic to disable double-tap zoom on mobile websites (Firefox disables it for non-zoomable pages only, as we did until this change).

The change is detectable by websites, but the compatibility impact should be fairly minimal:

- Developers that weren't doing anything special simply get faster clicks.

- Developers who had added "user-scalable=no" to their viewports to achieve faster clicks can optionally remove that when serving mobile/responsive sites to Chrome 32+ (unless they like the side-effect that it prevents users from pinch zooming, but this is sometimes frowned upon for accessibility reasons).

- Developers who were using libraries like fastclick can optionally remove them when serving mobile/responsive sites to Chrome 32+.

- Developers of libraries like fastclick should automatically disable the library if they detect the user is using Chrome 32+ and the page has a mobile viewport, like they already do if the page has a user-scalable=no viewport. A benefit of this, is that disabling fastclick's touch listener on document.body will allow scrolling the page to be better hardware accelerated.

- This change wasn't landed in time to affect the Chrome-powered WebView shipped in Android KitKat, so if you need fast clicks there, you can still set user-scalable=no (or use fastclick) for now.

Spec / OWP launch tracking bug / Link to entry on the feature dashboard

N/A as this is a UX change. Impl bug: crbug.com/169642. Patch: crrev.com/18850005.

[Mark Pilgrim]

On Mon, Nov 4, 2013 at 2:11 PM, John Mellor <joh...@google.com> wrote:
> - Developers of libraries like fastclick should automatically disable the
> library if they detect the user is using Chrome 32+ and the page has a
> mobile viewport, like they already do if the page has a user-scalable=no
> viewport.

Is there a way to detect this without resorting to User-Agent sniffing?

-Mark

[Darin Fisher]

FYI, I noticed in Chrome on Android that if I have "Settings > Accessibility > Force enable zoom" checked that clicks are still delayed by 300 msec on pages with user-scalable=no. This makes sense, but it wasn't obvious to me at first. I had to disable that option to see the effects of the demo using Chrome 30.

-Darin

[splin...@gmail.com]

I hope Chrome continues to offer that "Force Enable Zoom" option for accessibility reasons. It seems a fair compromise to me: if the site disables zoom primarily to feel more "app-like" and remove the delay, reintroducing the delay after the user made a conscious choice to override the zooming is then the "price" that user pays to enable the extra flexibility.

Extending the idea though, I'd posit that certain types of users (I'm thinking those with mobility impairments for instance, using something like switch access) it's easier to double-tap than it is to do a pinch-zoom gesture. So perhaps this proposed change would also warrant an additional checkbox a la "Force Enable Double-Tap to Zoom"?