Sandra, could you take a look?

What a coincidence, came here to report the same issue. It's so unpredictable and bad because of this, that I have to forget about this functionality completely.

What I can add is that it seems like the swipes seem to (in case of having a horizontal scroll) account not only the X axis, but also Y - so if you make a curved swipe, it counts the whole movement from A to B, and not only the difference on the axis we're interested in and you can end up with a REALLY fast swipe. Worth noting that it works in a similar fashion in Safari, but again - in a more predictable way.

Ideally what I would like to see is just the normal, native scroll behaviour and then snap near/at the very end of the movement...

One of our design goal was to ensure a small flick and a large flick in fact behave differently to allow user intended scroll affect which snap area the ended up at. The spec also has guidelines that suggests this.
I believe that is a good principle but perhaps our implementation can be tuned better.

The way we have set to achieve the above was to use the "natural ending point" of a flick to decide the snap area that we chose. Basically, if your flick (a.k.a momentum scroll/fling) would end up one slide over, or three slide over, we will pretend that is the "final scroll position" and use that to choose the snap area. I think in theory this should work nicely.


However in practice, in our current implementation we don't have the "natural end point" and we end up estimating it with some heuristic. I would not be surprised if this heuristic is not as accurate as we like which I believe can be perceived more clearly where precise control is desired (e.g., in your usecase). Do you have a video capture of the behavior? 

> This problem seems to get worse the more slides you have (seems like momentum is based on the scroll width, with a full swipe moving from one end to another).

Interesting, I wonder if this is a side effect of how we estimate? sunyunjia@ any ideas here? perhaps for larger scrollers we will get larger flings and more GSU which can lead to even larger estimation error values. Or maybe our estimation performs worth for larger values.


While the estimation approach was fine to start with, we have always intended to switch to using more accurate natural end point on platform where this is possible. I believe we can get this info on Android and CrOS but perhaps not Mac. Rather than trying to improve the estimation I like to see us get rid of it where possible. This should improve the android situation. 


Having said that, as you have found out, we intend to implement scroll-snap-stop for usecases where they always want to force a single slide (regardless of flick strength). But I feel we first need to fix the natural fling estimation issue since it will have broader improvements. Also not other vendor has implemented scroll-snap-stop yet.

re #2:

> so if you make a curved swipe, it counts the whole movement from A to B, and not only the difference on the axis we're interested in and you can end up with a REALLY fast swipe. Worth noting that it works in a similar fashion in Safari, but again - in a more predictable way.

Right, we do take the whole 2d movement into account in our estimation. So that is potentially possible though I have not tested it. However, Chrome has scroll railing on most platforms (e.g., it tends to ignore minor scroll delta in one axis in favor of 1d scrolls) so this should happen fairly rarely. What platform did you notice this, and  do you have a video screen capture of this to share?