-webkit-overflow-scrolling: touch; breaks in Apple's iOS8

Jamie Beech picture Jamie Beech · Oct 3, 2014 · Viewed 77.7k times · Source

I'm working on a web app that uses -webkit-overflow-scrolling:touch in several places to give the overflown divs inertia scrolling.

Since updating to IOS8, -webkit-overflow-scrolling: touch stops you being able to scroll whatsoever, and the only way I have been able to fix this so far is by removing -webkit-overflow-scrolling: touch which leaves the standard sticky scrolling. Please help!

Here is an example of one of the standard classes that works in iOS5, 6, and 7:

.dashboardScroll {
    height: 100%;
    overflow-x: hidden;
    overflow-y: scroll;
    -webkit-overflow-scrolling: touch; /*MAKES OVERFLOWN OBJECTS HAVE INERTIA SCROLLING*/
    -webkit-transform: translateZ(0px); /*HELPS THE ABOVE WORK IN IOS5*/
} 

Answer

Louis Féat picture Louis Féat · Nov 18, 2014

I had a similar problem with a (quite complex) nested scrollable div which scrolled fine in iOS 5, 6 and 7, but that intermittently failed to scroll in iOS 8.1.

The solution I found was to remove all the CSS that tricks the browser into using the GPU:

-webkit-transform: translateZ(0px);
-webkit-transform: translate3d(0,0,0);
-webkit-perspective: 1000;

By doing this, the '-webkit-overflow-scrolling: touch;' can still be included and still function as normal.

It did mean sacrificing the (for me, dubious) gains to scrolling performance that the above hacks gave in earlier incarnations of iOS, but in the choice between that and inertia scrolling, the inertia scrolling was deemed more important (and we don't support iOS 5 anymore).

I cannot at this stage say why this conflict exists; it may be that it is a bad implementation of these features, but I suspect there is something a bit deeper in the CSS that is causing it. I am currently trying to create a pared down HTML/CSS/JS configuration to demonstrate it, but maybe the heavy markup structure and the large amounts of dynamic data is necessary for it to happen.

Addendum: I did, however, have to point out to our client that if even with this fix the user starts trying to scroll on a non-scrollable element she will have to wait a second after stopping before being able to scroll the scrollable element. This is native behaviour.