1180167 - It's very hard to scroll to CSS scroll snap points that are close(-ish) together

Status: RESOLVED DUPLICATE of bug 1177842

(Core :: Panning and Zooming, defect)

Description

[Chris Lord [:cwiiis]]

The current scroll-snapping implementation in APZC take into account the velocity of the fling when choosing what snap point to snap to. This is good, but with the current default settings on b2g, it can be *very* hard to scroll to snap points that are close together. You can see this in the current task manager, where it's nearly impossible to scroll just one app across unless you make a concerted effort. You can also see this in my prototype homescreen with vertical paging, where it can be quite hard to scroll only one page, even though they're a screen apart.

I suggest that there should be some extra, large amount of friction that is applied, or perhaps a scale factor, when calculating what snap point to scroll to, so that it becomes easier to scroll between adjacent snap points.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Please provide a test case.

Comment 2

[Chris Lord [:cwiiis]]

See the attached URL - starting on a red square, it's quite hard to scroll to the adjacent green square (and vice-versa).

Comment 3

[Kartikaya Gupta (email:[e-mail])]

On a Flame it's harder than I would expect, but by no means impossible. Once I got the hang of it I could consistently swipe one from square to the next. I think this is largely a perception issue - where the user expects to end up is different from where the code computes you would end up, and so it snaps differently than you'd expect. I think we just need to adjust the code to be a little less "correct" and more tuned to user expectation (i.e. apply a greater friction value in its modeling of where the fling will terminate).

Comment 4

[Chris Lord [:cwiiis]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)
> On a Flame it's harder than I would expect, but by no means impossible. Once
> I got the hang of it I could consistently swipe one from square to the next.
> I think this is largely a perception issue - where the user expects to end
> up is different from where the code computes you would end up, and so it
> snaps differently than you'd expect. I think we just need to adjust the code
> to be a little less "correct" and more tuned to user expectation (i.e. apply
> a greater friction value in its modeling of where the fling will terminate).

I agree about the friction modelling. My example doesn't exhibit this quite as badly as where this comes up in Gaia (open 4+ apps, then long-press the home button and try to scroll by just one app across).

Comment 5

[Kartikaya Gupta (email:[e-mail])]

If you want to take a crack at this, the code for this is fairly self-contained. The computation of |predictedDelta| at [1] would need to be adjusted so that it uses a higher friction. The predicted destination sent over to the main thread would then be more in line with what the user expects, and so the snap should happen at an earlier coordinate. (It might also also be worth turning on the logging a few lines down to make sure the predicted destination is sane and the bug isn't in the main-thread code that picks the snap target).

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/AsyncPanZoomController.cpp?rev=5fa640a81855#2150