Bug 122212 – Optimizations to remove 350ms touch > mouse events delay

• Component: UI Events
• Status: RESOLVED FIXED

[Patrick H. Lauke]

Created attachment 213162 [details]
Comparison screenshot of Chrome/Android and iOS/Safari showing the events fired and delay on non-zoomable pages

Chrome and Firefox on touch-capable devices have optimizations in place to remove the 300ms delay between touchend and the simulated mouse events (which are generally there to wait for a second tap for a double-tap-to-zoom gesture) in situations where a page is explicitly set not to be zoomable anyway (classic examples: meta viewport set to user-scalable=no or with both minimum-scale and maximum-scale set to the same value).

Examples:

1) go to http://patrickhlauke.github.io/touch/tests/event-listener_user-scalable-no.html and tap the button
2) go to http://patrickhlauke.github.io/touch/tests/event-listener_minimum-maximum-scale.html and tap the button

It would be interesting to see similar optimizations being rolled into Webkit.

[Benjamin Poulain]

The key difference is Android does not support double-tap to scroll. Since there is no second tap to wait for, the synthetic mouse event is generated right away.

[Patrick H. Lauke]

"The key difference is Android does not support double-tap to scroll"

assuming you meant double-tap to zoom, that statement is incorrect. It's possible to double-tap to zoom in all browsers that I've tested on Android, and in particular in Chrome and Firefox. And on pages that do not have things like the meta viewport set to those non-zoomable values, there IS a ~300ms delay between touchend and the synthetic mouse events.

[Patrick H. Lauke]

Created attachment 213199 [details]
Chrome/Android on a page without the meta viewport set to user-scalable=no or min/max scale set to same number - delay is present

[Patrick H. Lauke]

Possibly of interest: further discussion around removing the 300ms delay over on the Chromium tracker https://code.google.com/p/chromium/issues/detail?id=169642

[Benjamin Poulain]

I did mean double tap to scroll.

[Patrick H. Lauke]

i'm embarassed to admit that despite being an iOS user for a good 5 years, i was unaware of the "double-tap to scroll" gesture. interesting, and i can see how this puts a spanner in the optimization works as currently present on android. wonder if it's still worth optimizing away when the page itself is not scrollable either in addition to not being zoomable, or if that's too much of an edge case to warrant it...

[Benjamin Poulain]

(In reply to comment #6)
> i'm embarassed to admit that despite being an iOS user for a good 5 years, i was unaware of the "double-tap to scroll" gesture. interesting, and i can see how this puts a spanner in the optimization works as currently present on android. wonder if it's still worth optimizing away when the page itself is not scrollable either in addition to not being zoomable, or if that's too much of an edge case to warrant it...

I see your point but I am not sure that would be a good direction for the Web platform.

Page scrolling is a far better model than touch scrolling or overflow scrolling. By providing a useful feature only if page scrolling is disabled, we would push developers away from the most efficient scrolling mechanism.

It would also be providing a feature only under certain layout conditions. I think it is bad from the engine to impose artificial constraints on web developers for arbitrary reasons (at that is also a fragile model).

Personally, I am more in favor of a solution involving a new kind of touch-action, or a declarative syntax with CSS.

[Binyamin]

Fixed on Chrome 32 http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

[Michał Gołębiowski-Owczarek]

I think it would help web applications way more if the double-tap to scroll gesture was removed and a similar optimizations of disabling detecting double-tap on narrow viewports was implemented than the current optimizing for scrolling.

It's way easier to scroll using a finger swipe than via double-tap. Besides, double-tap is usually recognized as a way of zooming-in & out so most people don't expect it to scroll.

On the other hand, having no way to react to taps faster than after 300ms of a tap kills any possibility of creating responsive complex web applications.

[Patrick H. Lauke]

anecdotal, perhaps, but also worth noting that of all long-time iOS users i've ever asked (during conference talks etc), nobody was aware of "double-tap to scroll". as far as i can tell, it's also not documented anywhere for end users...a "power user" feature that even power users seem unaware of?

[Benjamin Poulain]

We are getting quite a bit off tracks here.

Disabling double tap to scroll has nothing to do with WebKit. There is nothing actionable in WebKit, the right bug tracker to request the removal of double tap to scroll is bugreport.apple.com.

Regardless of that particular iOS feature, I think removing this delay based on viewport is a bad idea. That is just a ugly hack instead of adding proper handling for every possible page.

As I said in comment 7, I welcome any serious proposal to disable the double tap delay.

[Benjamin Poulain]

(In reply to comment #6)
> Unless I'm missing something, all that touch-action:manipulation in the context of touch events would do (and I believe that's what Chrome and Mozilla are implementing/have implemented so far) is a rather fancy way of saying "don't wait 300ms for the second tap of a double-tap action". Nothing about affecting raw vs adjusted position values as far as I know.

Following up from https://bugs.webkit.org/show_bug.cgi?id=133112:

I think an example will make things clearer:
-Let's say you have a link on which you want to remove the double tap delay for some reason. You add "touch-action:manipulation on the link".
-Now the user "tap" on the link. In general the finger position will not hit the line box of the link, instead it is a position slightly bellow the link. Since touch-action is defined for touch, it is ignored, and you get the double tap delay as usual.

[Patrick H. Lauke]

I'll leave the more technical details to the more knowledgeable folks like Rick, but: surely the touch-action:manipulation to suppress the delay applies to the entire hit box of the link?

[Iraê]

I would like to add one more link relevant... this was done in Chrome more then two years ago, and we've had a lot of trouble removing this delay programmatically on iOS on Yahoo Search.

It would be an incredible life-saver to have this implemented in Safari.

https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away

[Patrick H. Lauke]

Iraê, as was pointed out when I originally filed this issue (and that developer.google article also notes), iOS has a "double-tap to scroll" gesture which - assuming that it's still meant to stay in iOS, despite the fact it's not well known by users - needs to work even when width=device-width...

[Patrick H. Lauke]

However, I agree in principle that it would be good of the Webkit team to reconsider...as it stands http://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay iOS is the only mainstream mobile browser which does NOT optimize away those 300ms when width=device-width, and the only browser that still requires developers to use solutions like fastclick.js

[Iraê]

Regardless of how this is achieved, this is something that creates a gep between mobile  apps and cocoa apps. If one is writing a website with mobile layout, it does not matter how the click actually works, this becomes a minor improvement to the browser itself.

In the other hand, if you are writing an app, let's say a messenger client, a webmail client, a report panel for analytics and many, many other rich UI that you aim to have cocoa like interactions, such as Twitter does on mobile web, you would like this removed. Many libraries, including the ones linked in the links already listed, try to solve this issue.

I work at Yahoo, and countless developer hours, bugs and many sort of issues comes of a Javascript implementation trying to remove this delay. For Safari, it's probably easier to achieve that. Even if they implement as a new meta tag value, or if they remove this only when zoom is not available, or any solution, this is still something that would help a lot.

Besides, the solution Mobile Chrome took, of not zooming when content="width=device-width" is probably good enough for Safari too. This 300ms delay was introduced since the days the web where not even aware of mobile, it helped in the transition, and now we understand that it's not necessary anymore.

[Arthur]

Double tap to scroll seems like a really weird reason to not implement this. If developers want fast click then they will cancel double tap anyway via e.preventDefault(); since they are trying to achieve fast click via hack and implementation in JS. So here we just need a way for developers to disable 300ms when they need it, because double tap will be prevented anyway.

Disabling delay by the device-width meta tag probably won't work here since it's now commonly used in the wild, but touch-action or preventDefault(); on the toichend event could do the trick.

[Patrick H. Lauke]

> Disabling delay by the device-width meta tag probably won't work here since it's now commonly used in the wild

though, as mentioned, a lot of other browsers (Android/Chrome, Android/Firefox, FirefoxOS/Firefox, Windows Phone/IE, Windows Mobile/Edge) already do just that now.

[Rick Byers]

> Disabling double tap to scroll has nothing to do with WebKit. There is nothing actionable in WebKit, the right bug tracker to request the removal of double tap to scroll is bugreport.apple.com.

Benjamin, do you mean this is an iOS feature?  I can't find any other iOS apps that seem to implement it.  Or perhaps you just mean that it's a Safari feature that's not implemented in WebKit?

I continue to see sites that are broken / behave badly on all browsers only because they're using some sort of fastclick library which solves a problem that only exists on Safari.  Given how this is a big pain point for web developers, I'd argue it's at least indirectly a WebKit issue that should ideally be discussed with web developers in an open bug tracker somewhere.

Here's one idea: why isn't double-tap to scroll implemented as a default action of the second tap?  Presumably if double-tap zoom is disabled and a user double-taps on a button or link they almost certainly intend to activate it, not scroll.  I agree double tap to scroll is a nice feature - I could see adding it to Chrome if it didn't have such a catastrophic performance implication.  Sure there is the risk of UX confusion, but that's unavoidable without eliminating the double-tap gesture entirely (since developers largely use work-arounds to disable double-tap already).

Some usage data from Chrome which may be helpful in having a data-oriented debate here: 
 - only 0.6% of taps lead to a double tap
   - rises to 3.5% considering only sites where double tap is enabled
 - 75% (and increasing) of pages loaded on Android have a mobile viewport
 - 84% of taps (and increasing) occur on pages with a mobile viewport

[Rick Byers]

Looks like the delay was just removed in the most valuable case (non-scalable viewports) - bug 149968.  Yay!

[Chris Rebert]

Seems like Bug 149854 would offer a solution for the remainder of the problem (i.e. zoomable pages).

[Patrick H. Lauke]

Unless we want to keep this open purely for the width=device-width optimization (or is there a separate bug anywhere for that?), I'd say this can now be closed?

[Rick Byers]

(In reply to comment #23)
> Unless we want to keep this open purely for the width=device-width
> optimization (or is there a separate bug anywhere for that?), I'd say this
> can now be closed?

The initial-scale=1 (width=device-width) but still zoomable case is also really important IMHO.  As devs have complained about on twitter, encouraging sites to completely disable pinch zoom can be an accessibility issue (though Chrome at least has a force-enable-zoom option to get around that, not sure about Safari).

[Patrick H. Lauke]

Splitting out the width=device-width optimization into a standalone bug https://bugs.webkit.org/show_bug.cgi?id=150469 as the issues in the original bug's scope have all been addressed.