11 ms·
300ms tap delay removed on Chrome for Android
- kinlan 13y agoThe team are looking for a lot of feedback based on usage on this. Please either comment on the post or file feedback at crbug.com.
- primigenus 13y agoWe recently had to change our plans for a HTML5 game for smartphones because it performed like crap on Android. Now we're rebuilding it in Unity (with the recent 2d features they added) and it performs great. That's too bad, because we really believe in the idea of HTML5 as a cross-platform development environment. So I'm really happy with the obsessive pursuit of speed, responsiveness and user experience by the Chrome team. It's probably a good idea to seek feedback on this for accessibility reasons, but it feels like this change would be for the better when applying the 80/20 rule. This along with the numerous improvements to Chrome's developer tools and remote debugging features (https://developers.google.com/chrome-developer-tools/docs/remote-debugging https://developers.google.com/chrome-developer-tools/docs/re...) coming soon really show an increased focus on making high performance web apps on mobile a realistic option. Hopefully the next game we make will be able to launch on iOS and Android thanks to these speed improvements. :)
- kayoone 13y agoFor multiplatform games you are still better off with Unity imo. Sure, from a developer standpoint, building on open tech is cool, but gamers don't care at all and when Unity gives you the best possible performance and development workflow i would stick with it. They will also probably soon have a HTML5 export (they already have PNaCL)
- austinhallock 13y agoFor performance you're better of with Unity. For distribution you're better off with HTML5. You can get in the app stores & have distribution on the mobile web, have the game instantly playable in webviews, etc...
- kayoone 13y agoSounds great in theory, in practice mobile web views are pretty slow for games, as op already stated. Besides Unity will have a HTML5 export soon which will make it the most efficient tool for creating web games anyway.
- timsayshey 13y agoToo bad android chrome is not the same as the AOSP browser that is built in to android which is what the webview uses...
- martinml 13y agoThat's starting to change! Android 4.4 (KitKat) includes a new WebView component based on the Chromium open source project Will the new WebView auto-update? (...) There are large engineering and logistical challenges. We're not quite there yet, but we're working on it. https://developers.google.com/chrome/mobile/docs/webview/overview https://developers.google.com/chrome/mobile/docs/webview/ove...
- timsayshey 13y agoWow that's awesome news! I had no idea :)
- njs12345 13y agoLooks like someone's trying to make it possible to bundle Chromium with your app: https://github.com/pwnall/chromeview https://github.com/pwnall/chromeview
- pornel 13y agoThere never was any delay for touchstart/touchend events. If you're using onclick/mousedown in your game, then change them to touch events (touchstart and whatever Windows Phone does). These work without delay regardless of viewport settings. If you have existing codebase that can't be easily changed to use touch events, you can use FT Labs' fastclick to emulate onclick with no delay (the library is aware of latest Chrome's change): https://github.com/ftlabs/fastclick https://github.com/ftlabs/fastclick
- masklinn 13y ago> Microsoft's PointerEvents spec does the right thing and only fires pointerup if the touch doesn't trigger a lower-level action such as scrolling. I don't get how that helps for the use-case which triggered the original introduction of the tap delay: a double-tap is not a "lower-level" action than tap.
- jaffathecake 13y agoFrom the spec: "The user agent must dispatch a pointercancel (and subsequently a pointerout event) whenever all of the following are true, in order to end the stream of events for the pointer: The user agent has determined (via methods out of scope for this specification) that touch input is to be consumed for a touch behavior," Touch behaviours are things like scrolling, double-tap to zoom, pinch zoom. The browser's double-tap to zoom gesture is at a lower level than the click event in the browser. As in, a double-tab will be consumed by the browser and never hit the page.
- masklinn 13y agoThat precludes removing the delay, since that very delay is necessary to know whether it's a double tap.
- jaffathecake 13y agoDouble-tap precludes the click event. But touch/pointer events can preclude the double-tap.
- masklinn 13y ago> But touch/pointer events can preclude the double-tap. Your previous comment seems to imply otherwise: if the UA must dispatch pointercancel rather than pointerup on a double-tap, it has to wait until it can determine whether a double tap happened.
- jaffathecake 13y ago
- deleted 13y ago[deleted]
- JoelSutherland 13y agoFor what it's worth, this delay was already removed for sites that had user-scalable=no set. Most mobile "apps" used this. The change here is that if the computed viewport is smaller or equal to the device width, fast clicks will be enabled without having to disable scaling. Double clicking won't work, but pinch-to-zoom will. Overall it's a fairly minor change for those thinking about making HTML5 apps, but it is a big positive change for users visiting existing web sites that have mobile/responsive versions that haven't disallowed scaling.
- sluukkonen 13y ago> For what it's worth, this delay was already removed for sites that had user-scalable=no set. Most mobile "apps" used this. Is this true for mobile Safari as well?
- jaffathecake 13y agoNo, see the "Will other browsers do the same?" section of the article.
- sluukkonen 13y agoAh, that's too bad. It would be nice if setting user-scalable=no was all you had to do to disable the delay. And anyway, despite using an iPhone for god knows how many years, I didn't even know that a double tap on iOS scrolls the page! Edit: I mean double tapping on an unzoomable page.
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- jaffathecake 13y agoEven then, I think being able to pinch-zoom is a great feature and gives you some accessibility out-of-the-box.
- nodata 13y agoNice, but the video is unfair: in the slower video he moves his hand off camera and back every time, in the faster video he keeps it hovering above the phone. p.s. I think this is the Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=922896 https://bugzilla.mozilla.org/show_bug.cgi?id=922896
- spydum 13y agoI think that is to enforce the point, his hand could move away before the interaction registered visually.
- shawabawa3 13y agoI'm not sure why you need to wait for potential double taps on clickable elements anyway, couldn't you just have clickable elements not be double tappable?
- hmottestad 13y agoDouble tap to zoom is native support.
- emn13 13y agoI'm not sure how this matters - can you explain?
- hmottestad 13y agoIf you double tap a link on a desktop you will go to that link 'twice'. If you double tap a link on ios you will zoom to that link. Unless you wait for as long as a double tap takes you won't know if the user meant to zoom or to click the link. This is why there is discussion going on about the default view port and user zoomable content.
- emn13 13y agoI get that, but was thrown by your reference to "native" behavior - if you want to be able to double tap a clickable element, you'll need to wait long enough to discriminate the two behaviors. On the other hand - the desktop solution would be fine too; just don't solve the problem (i.e. you can't double-tap clickable content). I think I'd rather have fast responsive taps rather than double-tapping even on links; regardless of the zoomability settings.
- marijn 13y agoIndeed. That's how most desktop browsers handle double-click -- it only happens when the first click wasn't handled (preventDefault-ed). I guess they made this decision for usability reasons (double-tap-to-zoom should always work) but ended up creating a different problem instead.
- jackgavigan 13y agoWhy not add a "Zoom on double-tap" tickbox in Chrome's Settings? Leave it ticked as default so users aren't adversely affected. Even better, add another Setting to let users change the amount of time the browser waits for the second tap. Windows has had this since at least Windows XP (Start → Settings → Control Panel → Mouse → Double-Click) and I think since Windows 95. Set it to 300ms as default so existing users aren't adversely affected. People like me can set it to 180ms (which is what the iOS stopwatch indicates my maximum double-click delay is). If you want to put the icing on the cake, add a little applet in Settings to measure your double-tap speed.
- hyperpape 13y agoSettings don't get used. It's good to have nice flexible settings so people who investigate can make the device work the way they want, but most of the time people are using defaults, and developers spend the most time worrying about how to make their app/website work well with the defaults.
- jackgavigan 13y agoI would use it! That's all that matters! :-)
- jaffathecake 13y agoAre users adversely affected by this change? In what way? This change is designed to make the existing web faster. If we improve the performance of rendering, JavaScript, or scrolling, we don't put it behind an opt-in option. Why should this be?
- lukeschlather 13y agoIt's not so much the change as letting websites disable zoom. Letting websites disable zoom is a braindead user-hostile decision that could only have been made by people with perfect eyesight (or perfect glasses.)
- 13y ago
- a-priori 13y agoThis is cool and all, but it's a hack and it confuses the meanings of the viewport meta tags. Why should a "width=device-width" setting magically alter how touch events are processed? It makes no sense. Wouldn't it make more sense to introduce a new setting something like "immediate-events=yes" that lets developers opt-in to this behaviour?
- kinlan 13y agoThere is no spec that says how the events should be handled when the viewport is specified. IMO it shouldn't really be down to the developer to have immedidate-events etc because it is likely to be a user request (which they can currently override).
- poxrud 13y agoFor a solution for older browsers you can use fastclick.js (https://github.com/ftlabs/fastclick https://github.com/ftlabs/fastclick). For angularjs webapps there's also ngTouch.
- eliot_sykes 13y agongTouch is why I ought to get round to upgrading to Angular 1.2.x (currently on 1.0.x). One of the things ngTouch gives is "A more powerful replacement for the default ngClick designed to be used on touchscreen"[1]. Oh, I see its not bundled in the core angular.js file. [1] http://docs.angularjs.org/api/ngTouch http://docs.angularjs.org/api/ngTouch
- eliot_sykes 13y agoI don't recall why I've set it up like this, but I'm using the following in an app: <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">. Should the 300ms tap delay be gone in this case too, or is it only apps with precisely <meta name="viewport" content="width=device-width"> OR <meta name="viewport" content="width=device-width, user-scalable=no">?
- jaffathecake 13y agoThat removes the 300ms delay in Chrome and Firefox. Although you lose pinch zooming too, which can be a nice usability & accessibility feature.
- eliot_sykes 13y agoSo to be clear, as long as the content attribute contains "width=device-width", regardless of what comes after it, the 300ms is removed in those browsers?
- mbrubeck 13y agoFirefox currently disables the 300ms delay only if zooming is disabled (either with user-scalable=no or by setting identical min-zoom and max-zoom). We are discussing whether to follow Chromium's lead and also disable double-tap on pages with width=device-width: https://bugzilla.mozilla.org/show_bug.cgi?id=941995 https://bugzilla.mozilla.org/show_bug.cgi?id=941995 (I am a mobile Firefox developer.)
- barrkel 13y ago"Pinch-zooming is great for taking a closer look at a photo, some small print, or dealing with a set buttons/links that are placed too closely together. It's an out-of-the-box accessibility feature." No! Pinch-zooming is fantastic for navigating content. It lets you see an overview of the whole page, then zoom in on the bit you're interested in. It lets you control how much is seen on screen depending whether you want to read it in depth or skim it. It is a key feature of browsing the web on mobile devices. Mobile websites that disable pinch-zoom by using enormous text on extremely narrow fixed-width pages are a pessimization, and are almost always worse than the desktop page rendered on the mobile. That's my opinion. I search in vain for a browser whose "view in desktop mode" actually works.
- reubenmorais 13y ago>I search in vain for a browser whose "view in desktop mode" actually works. Have you tried Firefox for Android?
- barrkel 13y agoFirefox for Android is my primary browser on my Nexus 5 now that the AOSP browser has been removed. On my Nexus 4, I rooted the phone to get back to the AOSP browser, but when KitKat came out, it broke root. I haven't gotten around to re-rooting either phone. And no, the "view in desktop mode" toggle in Firefox for Android almost never works. I've considered rage-reporting bugs for all the URLs it fails on, but it's an idle fantasy right now. It clearly isn't a priority for Mozilla.
- maxerickson 13y agoThe view in desktop often fails when the site uses a mobile-specific url. That creates a problem that is hard for the browser to deal with cleanly.
- nodata 13y agoI haven't seen it fail, but I have only used the desktop view when coming from a page that then gets redirected to a mobile page. Firefox handles that well.
- daleharvey 13y agoNote that this is only different in the <meta name="viewport" content="width=device-width, user-scalable=no"> vs <meta name="viewport" content="width=device-width"> case, almost all browsers already remove the delay for user-scalable=no pages, but its a good improvement to be fast and still allow zooming, the article explains that, but I got confused skimming the title + first paragraph.
- jaffathecake 13y agoNot "almost all browsers", only Chrome and Firefox optimise it at the moment. IE and most importantly iOS Safari do not.
- skizm 13y agoI'm a big fan of the double tap to zoom. The browser figures out the zoom level you want with surprising accuracy and if it is wrong, or you want something specific you can always fall back to pinch zoom. I'm sure I'll adjust but I do wish this was an opt in/out thing.
- jaffathecake 13y agoThis only affects mobile-optimsied sites where double-tap zoom is pretty useless. Is there a page you;d find broken with this new behaviour? We're open to use cases.
- skizm 13y ago> This only affects mobile-optimsied sites where double-tap zoom is pretty useless. Sweet. I was thinking mostly about non-mobile sites so then this works. The only thing I can think of (and this isn't very often) is maybe images. For example on the mobile Wikipedia site there is often an image at the top of an article that I will double tap to zoom into and then another double tap to revert to normal zoom level. Definitely not the typical use case but something to consider. Maybe only have the 300ms when the first tap is on an image that is not a link. Just spit-balling here. Either way if it is only for mobile optimized sites, I don't see this being a problem.
- Pxtl 13y agoDouble-tap to auto-zoom seems like a misfeature anyways. Wasting a useful gesture like that on a somewhat-redundant action seems odd. A 2-finger tap gesture would've made more sense since it would be related to the pinch-operation.
- jaffathecake 13y agoCan't disagree with this. 2-finger tap to zoom to content. If only we could go back in time…
- snogglethorpe 13y agoA two-finger tap is extremely awkward to do with just your thumb... (often the only finger actually available)
- girvo 13y agoTry doing that with one hand.
- eyeface 13y agoI can't agree with this. The two-tap is my most common gesture on my phone's browser. A two-finger tap would be extremely awkward one-handed.
- jaffathecake 13y agoActually, fair point.
- recursive 13y agoMisfeature? Waste of a gesture? This is my most frequently used gesture on mobile browsers. Probably even more so than following links.
- sauravt 13y agoWith this feature implemented in stable branch of chrome and Chrome apps for android going stable in january 14, a lot of android.ios development will shift to making chrome apps that run on mobile.
- cbr 13y agoThis is excellent. Previously developers had to choose between their mobile site feeling snappy and supporting pinch-zooming. Now we can have both, and I can go back to being annoyed with developers who disable pinch-to-zoom.
- jblow 13y agoI agree that latency is terrible, but this is bad design that actually makes the situation worse. Now instead of a constant, learnable latency, you have latency that varies wildly depending on what page you are on. This is the wrong solution, in that it makes things more complicated and results in a generally poor experience even after the change. But that is what Google does all the time in UI, so I guess I have no reason to be surprised by this. The proper solution: Do not make double-tap be a UI action. Done. Or, if you insist on double-tap, make it only be an action that stacks transparently with single-tap. For example, in touch controls for The Witness, single-tap makes you walk toward the target. Double-tap makes you run. So as soon as we read a single tap, we can start doing the action without delay, and if we see the second tap we just kick up your target speed. It works great. In short, hey Google, please stop doing band-aid solutions that make things worse, and hire some people who really have solid design vision, and give them the power to get things done.
- jaffathecake 13y agoThis has been a behaviour for many versions of Chrome and Firefox for a while (zoomable sites vs non-zoomable) and we haven't seen confusion around this. This is why we have the beta, to test this stuff.
- jblow 13y agoI don't think "we haven't seen confusion around this" is a good answer. Most users will not even understand what is happening, they will just have an ambient level of uncomfortability with the UI that they don't know how to explain (not only due to this, but to many other factors as well, all of which contribute). Don't tell me that your users don't have an ambient level of uncomfortability with the UI, because we all know that is the case (it is even the case on iOS, now much more than it was with iOS 6!) If I were the UI lead for Android, I would be scouring the system from top to bottom, looking for ways to simplify and streamline, to increase predictability. All kinds of current UI actions would get thrown away (hint to Google Maps people: Shake is not an intentional UI action, it is what happens accidentally 5 times per minute when I am using your software. It should not be bound to anything, ever. [Apple is just as bad for binding shake to Undo, but at least theirs has a higher threshold now]. It is nice that at least now you can finally turn it off after it activates a few times, but haven't you noticed how everyone turns it off all the time, and nobody ever uses it for the intended action ["leave feedback"]? Get rid of it.) Anyway, all I can say to this response: "This is why we have the beta, to test this stuff." Is that if this attitude were actually solving all the problems that need to be solved, Android would have an amazing UI that everybody raves about. That is not the case! Why is it not the case?
- toadkick 13y agoHow about we instead stop turning off page zooming on mobile sites. The least of my concerns here is the stupid 300ms lag, when it seems like 80% of mobile sites these days don't even allow pinch-zooming anyway. Remember when one of the great things about smartphones was that you could use the "real" internet? Yeah. My poor eyeballs (and fat fingers) miss those days.
- jaffathecake 13y agoI don't know if you read the article, but the whole point is to drop the 300ms delay while retaining zooming.
- toadkick 13y agoI did read the article. Sorry, I conflated pinch-zoom with double-tap zooming. facepalm
- lm741 13y agoLatency sucks. You can apply this type of touch-click speedup on a site for other browsers with a bit of JS. https://gist.github.com/cagerton/7948779 https://gist.github.com/cagerton/7948779 (disclaimer: proof of concept, etc. )
- thegladiator 13y agodevelopers developing a site that is 'mobile friendly' is already overriding touch events to work around this latency issues. So OP's complaint about inconsistency is not valid. I'm sure many developers welcome this change.
- marcosscriven 13y agoI think a single 'long' press for zoom would have been a better way. By long I'd say 300ms or so. Then a short tap could act the moment you lifted your finger, assuming it was below the long tap threshold. iOS uses a long tap to select text though.
- deleted 13y ago[deleted]
- Raphael 13y agoIf one attempts a pinch now, won't the first finger to hit be interpreted as a drag instead? Or I suppose there is a drag delay but not a click delay.
- ajasmin 13y agoWhen taping a link, couldn't the browser start to load the page in the background even though the gesture may turn out to be a double-tap.