1531589 - Snap to snap positions on visible elements prior to positions on invisible element even if the positions on invisible element is closer to

Status: NEW

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[Hiroyuki Ikezoe (:hiro)]

Attachment: snap-visible-element-prior-to-invisible.html

The spec clearly says UAs should do that.

Since the purpose of scroll snapping is to align content within the viewport for optimal viewing, a scroll position cannot be considered a valid snap position if snapping to it would leave the contributing snap area entirely outside the snapport, even if it otherwise satisfies the required alignment of the snap area.

But as far as I can tell Chrome doesn't do it yet properly, and I am going to do it for programmatic scrolls (i.e. scrollTo, etc.) in bug 1373835, but for APZ cases it seems it needs scroll behavior changes in APZ.

Attaching file is an example to demonstrate this issue. If you scroll down to a point where the green box just appeared (at the point the blue box is out of view), snapping to the green box's top is the right behavior, but actually Chrome doesn't. I have an imcomplete patch for us it works as expected if you scroll down with dragging scrollbar but it doesn't work by wheel scrolling (probably we need machinery similar to OverscrollAnimation?)

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Attachment: The imcomplete patch

FWIW, here is the incomplete patch can be applied upon patches for bug 1312163, bug 1373835, bug 1373833 and bug 1373832.

Comment 2

[jonjohnjohnson]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #0)

Attaching file is an example to demonstrate this issue. If you scroll down to a point where the green box just appeared (at the point the blue box is out of view), snapping to the green box's top is the right behavior, but actually Chrome doesn't. I have an imcomplete patch for us it works as expected if you scroll down with dragging scrollbar but it doesn't work by wheel scrolling (probably we need machinery similar to OverscrollAnimation?)

I was about to file a separate issue for the strange/sporadic behavior exhibited in this link until I found this issue.

http://output.jsbin.com/subojom/9/quiet

Hiroyuki, if you load that link in webkit (desktop or iOS) you get an expected/smooth snapping experience. In chrome canary, though the snap-type is mandatory you get free scrolling (not snapping) logic in areas between images of the "slideshow". But in firefox nightly, you get snapping that almost always resolves in the opposite direction of the inertia left from a two finger scrolling flick, almost never resolving towards the intended direction.

I can't tell if it has the same root cause as your snap-visible-element-prior-to-invisible case, though when I very slowly execute my scrolling gestures and ensure showing the next snap area, our two test cases seem to behave similar???

What do you think?

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Oh yeah, it's very likely. But I can see the issue only on Android, can't see the issue on Desktop firefox, is that right? Coincidently I was told by kats that there is an issue on scroll snapping on Android, it's bug 1543195. Presumably, the bug is also somewhat related to.

I will check this later.

(By the way, the slide is pretty neat.)

Comment 4

[jonjohnjohnson]

Would it help you decide if my issue is encapsulated in yours by showing you a screencast of what I see in iOS (which is smooth) and desktop firefox nightly (which is super wacky/buggy)?

(thanks! :D it's a fun little demo that pushes the limit new scroll features)

I guess I just want to figure out if I should file it separately?

Comment 5

[jonjohnjohnson]

This is how I think it *should look in all browsers.
http://cl.ly/a52f53688393

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Attachment: Adapt the incomplete patch to the latest trunk

With patches for bug 1546057, bug 1546038 and this latest patch, the example in comment 2 works fine, as far as I can tell.