Sites incorrectly disabling scrolling with touch-action: none

[Rick Byers]

We've got a potentially serious issue with touch-action I'd like people's input on:

Several sites (about 6 known companies) are using a common gesture library hammer.js in a way that sets touch-action: none across the window when that's not their intention.  This means that Chrome 35 (soon to be stable channel) causes touch scrolling to be "broken" on those sites (since touch-action is on by default first in m35).  This was reported as a bug in hammer.js a year ago for having this same effect in IE, but the resolution was for consumers of the library to explicitly set a touchAction configuration to a suitable property.  I consider this a bug (or design flaw) in hammer.js and have reached out to the author, but that's not going to help in the short/medium term (since most sites presumably serve an old copy of hammer.js themselves).  Some of these sites have a work-around when they detect an IE user agent (like not using Hammer at all), but others are still broken on IE.

I see two main practical options:

1)

Disable touch-action support in chrome 35 to buy us some time (leaving it enabled in 36), then work with the hammer.js author to get hammer updated to be less error-prone here ASAP, and do some web-dev evangelism to encourage people to update to a new version of Hammer (possibly trying to contact a couple of the high profile sites).

Finding all sites affected or trying to contact dozens of site owners is unlikely to be practical.

It's not clear to me how successful this approach is likely to be.  If site owners haven't already noticed they're broken in chrome beta, will a bit of noise and another release or two help much?

2)

Ship as-is, evangelizing the issue to help developers understand quickly how to fix it when the inevitably notice their site is broken on Chrome Android. 

I considered a variety of more creative options (see list below), but I don't think any of them are really a worthwhile tradeoff relative to the above.  Other ideas?  If we're going to do anything other than #2, we need to decide ASAP.

Thanks,

   Rick

List of other potential ideas I don't think are worthwhile:

• Add a temporary hack that works around the specific bug with Hammer.  Eg. inject an alternate implementation of the 'Hammer' function into every page that first sets the touchAction configuration to 'auto' (if not already set) then invokes the real Hammer.  Injecting site-specific bug fixes like this seems evil - if we've never done it before, we probably shouldn't start for this.
• Try to find every site in this situation and reach out directly to as many as possible.  Most users of hammer should be unaffected (because they follow the advice of using hammer only on a small widget where disabling scrolling is appropriate, or because they explicitly set touchAction appropriately), so finding just those affected might be hard (maybe a distributed telemetry test that trys touch-scrolling the top 1 million sites with touch-action disabled and enabled looking for a difference).  Contacting site owners also looks difficult - after a bunch of searching we can't find any decent technical contact info currys.co.uk.  We don't have some way to leverage Google webmaster tools for sites that have opted into that, do we?
• Add a devtools warning if touch-action: none is used but the page never calls preventDefault on any touch events in the sequence.  This is a legitimate thing to do (especially if you've gone down a different codepath when you know touch-action is supported), but is probably not that common.
• Issue the above warning AND subsequently disable touch-action processing.  That way only the first gesture is busted and users can still mostly use the pages.  Again I'm worried about the false positives here.
• Abandon touch-action support entirely for the immediate future
• Rename touch-action to make sure it's opt-in, eg. -chrome-touch-action ;-)
• Disable just 'touch-action: none' while still handling the other cases.  This would probably cause a lot of confusion - 'none' is likely to be the most popular value (unless/until people start using manipulation everywhere to disable the click delay). 

[Adam Barth]

Seems like we should punt touch-action to M36 and evangelize these sites.  That gives them some breathing room to get their sites fixed.

Adam

[Matt Gaunt]

I think Adam is right. I'm going to update the Web Fundamentals doc on touch, including touch-action tomorrow afternoon. I may try and get a  H5R article done as well as and see if I can get that launched, unless you want to do that Rick ;).

--

Matt Gaunt

Developer Advocate

[Rick Byers]

Ok, touch-action has been flipped back to 'experimental' in M35 (for Android at least - final M35 desktop builds have already been produced).  https://code.google.com/p/chromium/issues/detail?id=372357

It's still enabled in M36+.  I've started evangelism with the key sites we know of and have started a google index search to try to identify other major sites - as well as get a better sense for the frequency of this (is it just a small fraction of hammer.js users that are completely broken?).

Matt, we can probably separate evangelism about touch-action from this specific issue.  It would be nice to have an H5R touch-action article at some point, but it's not urgent.  Once Jorik (hammer.js author) is back from vacation next week I'll work with him on a plan.  Hopefully we can get an update to hammer.js then just blast out a simple message encouraging web devs to upgrade to the latest hammer to avoid potentially being broken on Chrome 36+.

Rick

 

[Jacob Rossi]

Well this is unfortunate. :-/ But your plan seems pragmatic.  We can help with the outreach and possibly identifying additional affected sites. Rick, would you like to coordinate on that or do you think hearing it independently from both browser vendors is a good thing J?

 

FYI – also be on the lookout for old versions of YUI (less than v3.12.0) that had a similar issue when using their draggable control.  Though I believe we’ve successfully outreached to all the known affected  sites.

 

-Jacob

[Rick Byers]

On Fri, May 16, 2014 at 12:25 AM, Jacob Rossi <Jacob...@microsoft.com> wrote:

Well this is unfortunate. :-/ But your plan seems pragmatic.  We can help with the outreach and possibly identifying additional affected sites. Rick, would you like to coordinate on that or do you think hearing it independently from both browser vendors is a good thing J?

Thanks Jacob!  I'd love to co-ordinate on that - I don't think we have anywhere near the expertise at this sort of outreach as you do (I've just been submitting support requests myself using 'contact us' forms on the website).  I think it's fine (even preferable) to divide and conquer here (chance are if they're unresponsive to one of us, they'll be unresponsive to both too).  We can each mention that it effects IE, Chrome and soon Firefox.  We found some sites just disable hammer on IE so those you'll probably want to leave to us.

  

FYI – also be on the lookout for old versions of YUI (less than v3.12.0) that had a similar issue when using their draggable control.  Though I believe we’ve successfully outreached to all the known affected  sites.

Thanks for the heads up!  Man it's great to be working towards the same goals <grin>.  Mozilla owes us both a beer here - they're going to have it easy by the time they ship touch-action...

[Jacob Rossi]

> Thanks Jacob!  I'd love to co-ordinate on that - I don't think we have anywhere near the expertise at this sort of outreach as you do (I've just been submitting support requests myself using 'contact us' forms on the website).  I think it's fine (even preferable) to divide and conquer here (chance are if they're unresponsive to one of us, they'll be unresponsive to both too).  We can each mention that it effects IE, Chrome and soon Firefox.  We found some sites just disable hammer on IE so those you'll probably want to leave to us.

 

K – I’ll follow up with you directly on how we can tag team this. We’re interested in the sites that disable hammer too as that probably means we’re getting a degraded touch experience.

 

> Thanks for the heads up!  Man it's great to be working towards the same goals <grin>.  Mozilla owes us both a beer here - they're going to have it easy by the time they ship touch-action...

 

If you’re nice, maybe mbrubeck will send you a delicious cake.  Perhaps some beer should go to the site owners as an incentive to fix their code. :-D

[Jorik Tangelder]

First off, for me it's is a great choice to wait one release with Chrome, it gives devs some time to fix this issue. Thanks! (And sorry for the trouble)

The main reason why Hammer breaks this, is because I just never had the chance to do some serious testing with the ms pointer events (and thus touch-action), only some quick testing in a local computer-store. I found out that touch-action: none fixed a lot of issues, with the side effect that the instance element prevented scrolling on the element. It's a bigger deal when that element is larger than the viewport, like the body element. There's some documentation about this in the code and the wiki that people should change this property, but i guess most people don't read this.

I will create a wiki page telling what touch-action value should be used per gesture, and how to fix the current implementation. Settings the default value from 'none' to 'pan-y' would fix in many cases the issue, since people mainly use the horizontal swipe/drag gesture. 

Maybe with some help of some retweets and popular newsletters (like jsweekly) we can get devs to notice this. The fix would be just to change the default value of the setting, upgrading to the latest version could potentially break things. Contacting all devs would be impossible like Rick said, but maybe just for some large sites?

This week I will release a update to Hammer this week that set's pan-y as the default!

Jorik

[Jacob Rossi]

Thanks, Jorik, for jumping in and working on a fix!   The pan-y default seems like a reasonable stop gap solution. I’ll see what we can do to help advertise this out to web devs once the fix is in place.

 

Longer term, have you considered trying to determine the appropriate value per element based on the gesture(s) registered for?  For example:

 

Hammer(el).on("swipeleft", function() {

    //In this case, touch-action: pan-y; is probably best

});

 

Hammer(el).on("swiperight", function() {

    //In this case, touch-action: pan-x; is probably best

});

 

This might be a little tricky when multiple gestures are combined on the same element (you need to determine the configuration that allows all the gestures listened to). But that should be doable and I can help work through it with you if you like. I’ll paste this into the issue over on GitHub, where we can discuss further.

 

-Jacob