You need to
before you can comment on or make changes to this bug.
Created an attachment (id=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).
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.
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.
"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.
Created an attachment (id=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
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
I did mean double tap to scroll.
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...
(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.
Fixed on Chrome 32 http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
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.
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?
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.