Scrolling not working on Chrome for Android Beta (v35)

[mydea]

I use Hammer.js for horizontal gestures on list elements - the user can swipe left or right on list elements for additional options.

While I got this to work on Chrome for Android (v34) and on the Stock Browser on a Galaxy S2, I can't scroll on Chrome for Android Beta (v35). While the swipe gestures are working correctly, scrolling is not possible.

I have the following configuration (copy & pasted it together from various posts I found about this topic):

swipe_velocity: 0.2,
swipeVelocityX: 0.2,
swipe_time: 300,
dragLockToAxis: true,
dragBlockHorizontal: true,
drag: true,
drag_block_horizontal: true,
drag_lock_min_distance: 20,
hold: false,
release: true,
tap: false,
touch: true,
transform: false

I don't know if it is a bug in Chrome or another problem.

[jdduke]

This appears to be an issue related to improper use of the "touch-action: none" property in hammer.js, see https://code.google.com/p/chromium/issues/detail?id=372357 for details. You might consider using "touch-action: pan-y" as a replacement on elements for which you want to allow vertical scrolling.

[RByers]

Copying my comments from #241:

Jorik, why is touch-action: none the default when you're not going to call preventDefault on all touch events? That seems inconsistent. If you're not sure that you're going to want to disable scrolling etc. then you should leave touch-action set to auto I think, right? Specific gestures that override scrolling behavior could then set the appropriate touch-action (eg. swipeleft/swiperight can set touch-action: pan-y to disable horizontal scrolling).

[jtangelder]

#241 (comment)

[andymerskin]

Unfortunately, even after setting touch-action: pan-y or auto, my hammer.js-enabled website still isn't working correctly.

I've updated to the latest modified 1.1.3 build where touchActions has been defaulted to pan-y, but the element I have touch events attached to and overflow-y set to scroll will not scroll on my Nexus 5 running the very latest version of Chrome stable (35.0.1916.141), and beta (36.0.1985.65).

My project was working flawlessly a few weeks ago, before Google made the change to their code. I had some other work come up since then, and I revisited my project today to find that my element's content no longer scrolls.

The other funny thing is, if I use the Inspector via USB debugging and mouseover this element in the Elements tab (so that it highlights on my Nexus 5), then scroll the element, it works fine. The moment I move my mouse off the element in the Elements tab in the inspector, it no longer scrolls.

This little video will show you what I mean.

[RByers]

That sounds suspiciously like a Chrome hit-testing bug to me, not related to touch-action (which isn't enabled in Chrome 35) and possibly unrelated to hammer. Can you file a bug at crbug.com/new with repro steps (reply with the link here) and we'll investigate?

[RyanMG]

I was having the same issue as docmars is an application I was working on. Some of my elements were scrollable in chrome android, and some were not. All would scroll just fine if I opened DevTools and hovered over an element.

I stripped HammerJS out of my code base, and it did not solve the problem. What DID solve the issue is a head scratcher, but here it is:

I noticed that all my scrollable elements that WERE working had one thing in common. The actual containing element with 'overflow: scroll / auto' had a single element underneath it that contained all the content of the scrollable element. The ones that would not scroll had all the children just lumped as direct descendants of the scrollable element.

Adding a junk div child, and putting all other children in it, solved the problem.

So for example:

<div class="i-can-scroll">
  <el>
  <el>
</div>

was not working, but

<div class="i-can-scroll">
  <div class="container">
    <el>
    <el>
  </div>
</div>

worked. Weird, but what can you do.

[andymerskin]

@RyanMG Thanks for looking into this! For what seems like such a common use case on the mobile web, it's a pretty silly bug.

[charandas]

@RyanMG thanks for suggesting the workaround above. I tried it but doesn't seem to work for me. I seem to be in little different situation though. Touch scrolling breaks for me on desktop Chrome, but not 100% of time, its more like 85-90% of the time. It resumes if I open devtools or move the mouse cursor.

Of course, Chrome versions have moved on since you chatted here about this. I am using 46. Did you find anything more conclusive about this issue?

I am using hammer 2.0 to disable some events on the app global container, namely:
transform dragleft dragright swipe swipeleft swiperight

On top of it, I am using angular. So these elements are in an ng-repeat. Once the scroll breaks, if I don't resort to the mouse, the scrollbars do work with touch, but that's medieval. Why would pan-to-scroll be so difficult, I wonder. Anyway, cannot reproduce this issue with Canary.

Tried several chromium builds, thinking its this fix that made a difference, but haven't been able to prove that to myself.

[RByers]

Yes @majido has fixed at least one problem like that recently.

Weird, but what can you do.

As I mentioned above, you can filed a bug with repro steps and we'll get it fixed in the next Chrome release! If you can still reproduce an issue on Chrome 47+ (especially if removing hammer makes no difference) then PLEASE file a bug with repro steps and we will get it fixed ASAP.

For what seems like such a common use case on the mobile web, it's a pretty silly bug.

This stuff is complicated (and a little brittle) because of our threaded scrolling architecture where we want handle touch scrolling completely in our compositor without blocking on the blink thread (which is the only thread that knows about the DOM in any detail). Sorry for the pain this is causing!

[charandas]

Thanks @RByers for the detailed response.

I cannot reproduce my issues with Chrome Canary 48.0.2547.0, but downloading chromium builds until 48.0.2527.0 hasn't given me the same successful results.

I was hoping I could pin it to a commit, so I can watch out for it in upcoming chrome releases, but haven't been able to in my brief testing. Which commit by @majido are you mentioning about - I am curious?

I also downloaded Sawbuck and ran with chrome and chrome frame set to verbose. But when the locking freezes, or in general, I don't get any messages from the renderer. Perhaps I am missing something.

[RByers]

I was hoping I could pin it to a commit, so I can watch out for it in upcoming chrome releases, but haven't been able to in my brief testing. Which commit by @majido are you mentioning about - I am curious?

Just the bug you found. I took a quick look through the other changes I was thinking about, and they all seem unlikely to be your issue. I'd suggest trying Chrome Beta, if you don't see any problems there then it's likely to be fixed with Majid's change.

[charandas]

@RByers yes, I don't see the problem in the beta version. Do you know when the next release of chrome is going to be out, in other words, when will this beta be promoted to stable?

[RByers]

Chrome is released about every 6 weeks, and Chrome 46 went stable on Oct 13. So I'd guess early December 47 should get promoted to stable.