|Summary:||Optimizations to remove 350ms touch > mouse events delay|
|Product:||WebKit||Reporter:||Patrick H. Lauke <redux>|
|Component:||UI Events||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||7raivis, benjamin, binh.phan, bregenspan, dpcalhoun, irae, m.goleb+bugzilla, nekr.fabula, rbyers, sam, simon.fraser, webkit, wenson_hsieh, yahoomobile|
|Version:||528+ (Nightly build)|
|Bug Depends on:||149854, 149968, 150248, 150604|
Description Patrick H. Lauke 2013-10-02 04:20:51 PDT
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.
Comment 1 Benjamin Poulain 2013-10-02 13:39:54 PDT
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.
Comment 2 Patrick H. Lauke 2013-10-02 14:25:39 PDT
"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.
Comment 3 Patrick H. Lauke 2013-10-02 14:29:04 PDT
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
Comment 4 Patrick H. Lauke 2013-10-02 14:53:48 PDT
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
Comment 5 Benjamin Poulain 2013-10-02 15:49:09 PDT
I did mean double tap to scroll.
Comment 6 Patrick H. Lauke 2013-10-03 00:18:46 PDT
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...
Comment 7 Benjamin Poulain 2013-10-03 13:53:57 PDT
(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.
Comment 8 Binyamin 2013-12-15 02:05:57 PST
Fixed on Chrome 32 http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
Comment 9 Michał Gołębiowski-Owczarek 2014-04-03 07:02:45 PDT
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.
Comment 10 Patrick H. Lauke 2014-04-03 11:07:48 PDT
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?
Comment 11 Benjamin Poulain 2014-04-03 18:25:53 PDT
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.
Comment 12 Benjamin Poulain 2014-05-20 14:00:34 PDT
(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.
Comment 13 Patrick H. Lauke 2014-05-20 14:06:40 PDT
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?
Comment 14 Iraê 2015-08-07 14:33:41 PDT
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
Comment 15 Patrick H. Lauke 2015-08-07 15:01:33 PDT
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...
Comment 16 Patrick H. Lauke 2015-08-07 15:03:50 PDT
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
Comment 17 Iraê 2015-08-10 11:23:06 PDT
Comment 18 Arthur 2015-08-10 13:42:27 PDT
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.
Comment 19 Patrick H. Lauke 2015-08-11 00:54:02 PDT
> 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.
Comment 20 Rick Byers 2015-08-24 08:30:36 PDT
> 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
Comment 21 Rick Byers 2015-10-14 15:44:14 PDT
Looks like the delay was just removed in the most valuable case (non-scalable viewports) - bug 149968. Yay!
Comment 22 Chris Rebert 2015-10-14 16:26:20 PDT
Seems like Bug 149854 would offer a solution for the remainder of the problem (i.e. zoomable pages).
Comment 23 Patrick H. Lauke 2015-10-22 07:11:53 PDT
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?
Comment 24 Rick Byers 2015-10-22 07:27:45 PDT
(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).