300ms tap delay removed on Chrome for Android

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

by groodt • 13 years ago

309 159 13 years ago

updates.html5rocks.com

kinlan7• 13 years ago

The 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• 13 years ago

We 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/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. :)

kayoone2• 13 years ago

For 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• 13 years ago

For 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...

timsayshey2• 13 years ago

Too bad android chrome is not the same as the AOSP browser that is built in to android which is what the webview uses...

martinml• 13 years ago

That'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/ove...

njs12345• 13 years ago

Looks like someone's trying to make it possible to bundle Chromium with your app: https://github.com/pwnall/chromeview

pornel• 13 years ago

There 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

masklinn5• 13 years 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.

jaffathecake30• 13 years ago

From 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.

masklinn5• 13 years ago

That precludes removing the delay, since that very delay is necessary to know whether it's a double tap.

JoelSutherland• 13 years ago

For 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.

sluukkonen2• 13 years 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?

jaffathecake30• 13 years ago

No, see the "Will other browsers do the same?" section of the article.

nodata2• 13 years ago

Nice, 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

spydum• 13 years ago

I think that is to enforce the point, his hand could move away before the interaction registered visually.

bbrks• 13 years ago

That, and also if you tap too quickly, it will just trigger the tap to zoom feature. So you have to wait that long anyway regardless of where your hand is placed.

kinlan7• 13 years ago

it was.

shawabawa3• 13 years ago

I'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?

hmottestad2• 13 years ago

Double tap to zoom is native support.

emn132• 13 years ago

I'm not sure how this matters - can you explain?

marijn• 13 years ago

Indeed. 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.

sp332• 13 years ago

Sometimes I want to zoom in on a tappable picture. And sometimes the text is so small that I can't aim accurately until I zoom in.

jaffathecake30• 13 years ago

You can actually try this out in Chrome Android Beta. Go to about:flags and enable "Disable tap delay".

Here are the problem cases:

* Delegated event listeners - as in the click handler is on the html/body element. The listener may do something when a click happens, it may not. This means everything is potentially clickable, and we can't know in advance.

* Large click areas - Areas where the article title, summary and picture are all part of the same link. It's not always clear at first, but you'd be surprised how often you trigger it by accident.

But give it a go yourself!

jackgavigan6• 13 years ago

Why 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• 13 years ago

Settings 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.

jackgavigan6• 13 years ago

I would use it! That's all that matters! :-)

jaffathecake30• 13 years ago

Are 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?

lukeschlather2• 13 years ago

It'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.)

jackgavigan6• 13 years ago

Well, I'm not suggesting they do my idea instead of what they've done. I'm suggesting they do it in addition to what they've done.

I hate the delay between tapping the screen and the "click" being recognised. It drives me up the wall. I'd far rather switch off "Double-tap to zoom" for all pages (not just those with the relevant meta-tag) and use pinch-to-zoom instead.

There are obviously very good reasons to not disable "Double-tap to zoom" entirely or by default (primarily accessibility, but also the fact that people have gotten used to it) but where's the downside in making it a Setting so that people like me can choose to disable it? Okay, maybe the upside is quite small but there's zero downside and (given that they've already implemented the ability to switch "Double-tap to zoom" off if the webpage has the relevant meta-tag) it would be relatively easy to implement.

Making stuff like this user-configurable is a Good Thing. It's like when Apple changed the behaviour of the iPad's side switch in iOS 4.2 to switch it from rotation lock to audio mute and Steve Jobs said there wouldn't be a configuration option to let users change the switch back to rotation-lock [1]. A lot of people (including me) were disappointed. Fortunately, he changed his mind and iOS 4.3 made the function of the side-switch user-configurable in the Settings.

[1] http://9to5mac.com/2010/10/23/jobs-there-wont-be-a-mute-swit...

poxrud• 13 years ago

For a solution for older browsers you can use fastclick.js (https://github.com/ftlabs/fastclick). For angularjs webapps there's also ngTouch.

eliot_sykes3• 13 years ago

ngTouch 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

eliot_sykes3• 13 years ago

I 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">?

jaffathecake30• 13 years ago

That removes the 300ms delay in Chrome and Firefox. Although you lose pinch zooming too, which can be a nice usability & accessibility feature.

eliot_sykes3• 13 years ago

So 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?

a-priori• 13 years ago

This 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?

kinlan7• 13 years ago

There 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).

barrkel2• 13 years 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• 13 years ago

I search in vain for a browser whose "view in desktop mode" actually works.

Have you tried Firefox for Android?

barrkel2• 13 years ago

Firefox 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.

Pxtl2• 13 years ago

I still use a WinPhone7 phone and many of these "mobile" sites are completely broken on WP7 IE - they frequenetly have images or boxes that extend outside the bounds of the fixed-width area and don't allow me to zoom out or pan right to see the whole thing.

mjolk• 13 years ago

That's your phone's fault, not the website's.

untog3• 13 years ago

That's because the Windows Phone 7 browser is unfathomably awful. I say this as a one-time WP7 user and a web developer.

I felt guilty for using it because there was an outside chance it might make someone have to develop for it.

sarah2079• 13 years ago

This isn't just your phone. I encounter this specific problem a lot on an iPhone 5 running iOS 6. (And it is just one of the many irritating bugs with mobile sites that I see regularly).

guelo• 13 years ago

You want the "Always Zoom" Add-on in Firefox for Android.

bluthru• 13 years ago

Especially now that phones have high-res screens. No need for everything to be dumbed down to a single column that's 8 words wide.

jaffathecake30• 13 years ago

It's not about resolution, it's about angle of view (http://en.wikipedia.org/wiki/Angle_of_view).

My phone has the same resolution as my computer monitor and 45" TV. But due to size and viewing distance, the same font & image sizes shouldn't be used on all.

This is why we have ppx/device-pixel-ratio on the web.

gohrt2• 13 years ago

dumbed down

???

Longer columns doesn't take higher intelligence, it just strains your eyes.

http://baymard.com/blog/line-length-readability

Have you ever seen a print edition of the NYT or WSJ?

sneak2• 13 years ago

Amen. I wish there were a MobileSafari preference to ignore all the terrible viewport business (I am so fucking sick of websites with tiny type disabling my ability to zoom!) and send a desktop safari user-agent on top.

Even Motherfucking Website[1] cocks this one up and disables zooming.

[1] http://motherfuckingwebsite.com

caryhartline• 13 years ago

Disabling the viewport on websites that need zoom is really bad design, but if you have a website that is optimized or at least scales well to mobile sizes then disabling zoom is better. If the user doesn't have a reason to zoom on to content then accidentally zooming makes for a worse experience.

Although I agree that there should be an option to disable the disabling of viewport zooming; I think it makes for a better UX for most mobile website viewers.

andrethegiant• 13 years ago

I am so fucking sick of websites with tiny type disabling my ability to zoom!

Me too! I made a bookmarklet[1] that restores your ability to zoom on sites that explicitly disable it.

[1] https://gist.github.com/jasonbarry/6047338

kalleboo• 13 years ago

One of my favorite iOS Chrome features is "request desktop version"

buro92• 13 years ago

Or a browser that leaves the font size alone and doesn't try and guess what size the font should be by some invisible algorithm that factors in things like the depth of the text node in the DOM.

You hit some sites, and fonts that should be the same size (and are on the desktop site) are just wildly different sizes.

I'm using Dolphin almost exclusively for this single reason.

kinlan7• 13 years ago

Out of interest what does dolphin do? Does it just leave the text as is?

MichaelGG• 13 years ago

Is that what Android Chrome is doing on Hacker News? I remember reading it sometimes and seeing some comments being larger than others. I thought it was some crazy mobile optimization based on votes but it didn't seem to have any logic it to it.

gohrt2• 13 years ago

> some small print,
No! [...] then zoom in on the bit you're interested in.

??? Why "No"

    Deskop pages also have a habit of being laid out with very long lines that don't reflow when you zoom in, this is 
    bad in general (narrow columns are more readable) but especially bad on a portrait-orientation device.

duaneb• 13 years ago

The need for two fingers to navigate a page annoys me far more than text size.

nfoz• 13 years ago

It is a problem with the user-agent if it does not allow the user to zoom, and I don't care what the page markup says. Zooming can be a function of the display and not the page layout. An, um, "content zoom" is a different thing entirely.

daleharvey• 13 years ago

Note 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.

jaffathecake30• 13 years ago

Not "almost all browsers", only Chrome and Firefox optimise it at the moment. IE and most importantly iOS Safari do not.

skizm2• 13 years ago

I'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.

jaffathecake30• 13 years ago

This 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.

skizm2• 13 years 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.

Pxtl2• 13 years ago

Double-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.

jaffathecake30• 13 years ago

Can't disagree with this. 2-finger tap to zoom to content. If only we could go back in time…

snogglethorpe• 13 years ago

A two-finger tap is extremely awkward to do with just your thumb... (often the only finger actually available)

girvo2• 13 years ago

Try doing that with one hand.

eyeface• 13 years ago

I 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.

jaffathecake30• 13 years ago

Actually, fair point.

recursive• 13 years ago

Misfeature? Waste of a gesture? This is my most frequently used gesture on mobile browsers. Probably even more so than following links.

sauravt• 13 years ago

With 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• 13 years ago

This 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.

jblow6• 13 years ago

I 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.

jaffathecake30• 13 years ago

This 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.

jblow6• 13 years ago

I 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?

tracker1• 13 years ago

I hate non-zoomable sites, even when "mobile friendly" sometimes the fonts on my phone are too small, even in mobile, or I'd like to zoom in on an image a bit.. I'd rather have the delay... (actually I'd rather nuke double-tap to zoom)

stanleydrew• 13 years ago

I assume they discussed removing double-tap as an action but decided it would be too disruptive. I can't say I disagree with the choice they made.

I don't believe the problem you brought up is very important. Why do I care if there is a "constant, learnable latency", as long as each latency is reasonable? In the end I assume that the slowest response is the standard and any actions that happen faster are a pleasant surprise.

But more importantly this change doesn't preclude them from removing double-tap altogether in the future. I agree it is a half-solution now, but it's better than nothing if you are willing to grant that differing latency across pages is acceptable.

I do like the insight about stacking double-tap on top of single-tap, I'm just not sure how to apply it in the current world where single-tap means click/navigate and double-tap means zoom.

jblow6• 13 years ago

The impact of variable latency is well-known among people who actually study human factors. It makes it hard for your brain to internalize interactions and make them automatic, and it increases the feeling of frustration.

In video games specifically, where I work, it is well-known that you would rather have a game that runs slower, but with a solid frame rate, than a game that has a highly-variable frame rate that is faster on average. (This is more of a continuum situation than a discrete action like a tap, but the basic principle holds).

P.S./edit: Double-tap only means zoom because that is what they happened to implement. It is a convention easily changed. Look at how heavily Apple just revamped their entire interface, for an audience that is arguably much less savvy than the Android audience.

Using double-tap in this way was a mistake; it is an easy mistake to fix if you have enough design vision to know where you are going.

rayiner• 13 years ago

Why do I care if there is a "constant, learnable latency", as long as each latency is reasonable?

Because people would rather have slower and more predictable than faster and less predictable. Especially when it comes to user interface actions where things get pushed down into muscle memory.

toadkick2• 13 years ago

How 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.

jaffathecake30• 13 years ago

I don't know if you read the article, but the whole point is to drop the 300ms delay while retaining zooming.

toadkick2• 13 years ago

I did read the article. Sorry, I conflated pinch-zoom with double-tap zooming. facepalm

lm741• 13 years ago

Latency 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 (disclaimer: proof of concept, etc. )

thegladiator• 13 years ago

developers 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• 13 years ago

I 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.

Raphael• 13 years ago

If 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• 13 years ago

When 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.

300ms tap delay removed on Chrome for Android

Related Stories