1545316 - [css-scroll-snap] Are start/end scroll boundaries supposed to create "implicit" snap areas? compat w/webkit

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[jonjohnjohnson]

Attachment: snapcase.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Steps to reproduce the problem:

1. Open test case with trackpad connected to computer
2. On load, notice green scroll container is resting (though not snapped) at the scroll position of zero.
3. Two finger gesture scroll downwards.
4. Notice snapping to the center of the pink block within scroll container.
5. Try to scroll to the top or bottom boundaries of scroll container and see snapping always resolves back to the pink blocks center.

Aside, on a fresh load, a click inside the green scroll container executes the scroll snapping, even without ever scrolling.

Tangentially, see the second scroll container in the case, which uses proximity, here you can actually trick the browser into snapping at an edge, but only from doing the gesture towards the opposite boundary. Try scrolling the second container towards the top with a lot of force... and it snaps to the bottom haha. :D

Actual results:

A user can never resolve the scroll/snap container at the start/end edges, even if on load the container rests at the start. :(

Expected results:

I'm not sure that the spec says implicit snap areas should be created at start/end edges of snapports, but you can see webkit does create them when accessing this test case. And it seems to me the more logical behavior.

https://drafts.csswg.org/css-scroll-snap-1/#choosing

Side note, blink behaves the same as gecko, though a users scrolling, not just clicking is needed to initiate snapping.

Comment 1

[jonjohnjohnson]

Video of scrolling behaviors in description - http://cl.ly/bf19088e31a4

If the proximity issue is not encapsulated in the implicit start/end boundary snapping, feel free to break it out to separate ticket?

Comment 2

[Hiroyuki Ikezoe (:hiro)]

I can't reproduce this issue on my Linux box and on an Android phone either.
(In reply to jonjohnjohnson from comment #0)

Steps to reproduce the problem:

1. Open test case with trackpad connected to computer
2. On load, notice green scroll container is resting (though not snapped) at the scroll position of zero.
3. Two finger gesture scroll downwards.
4. Notice snapping to the center of the pink block within scroll container.
5. Try to scroll to the top or bottom boundaries of scroll container and see snapping always resolves back to the pink blocks center.

Aside, on a fresh load, a click inside the green scroll container executes the scroll snapping, even without ever scrolling.

Tangentially, see the second scroll container in the case, which uses proximity, here you can actually trick the browser into snapping at an edge, but only from doing the gesture towards the opposite boundary. Try scrolling the second container towards the top with a lot of force... and it snaps to the bottom haha. :D

This "bounce back" effect sounds like bug 1543195, but I can't reproduce it on the Android phone at all. Maybe an issue on MacOSX touchpad code? I am totally unsure though.

Actual results:

A user can never resolve the scroll/snap container at the start/end edges, even if on load the container rests at the start. :(

Expected results:

I'm not sure that the spec says implicit snap areas should be created at start/end edges of snapports, but you can see webkit does create them when accessing this test case. And it seems to me the more logical behavior.

https://drafts.csswg.org/css-scroll-snap-1/#choosing

Hmm, to me the current behavior is what the spec defines.

Comment 3

[jonjohnjohnson]

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

Hmm, to me the current behavior is what the spec defines.

I guess it just seems weird that, on load, a scroll/snap container can resolve at an edge that once scrolled (or clicked even) is never allowed to resolve back to that edge.

As well as webkit deciding to ignore the spec, if this is the case. :/

Comment 4

[jonjohnjohnson]

In case the blink folks decide differently, here's the report of their similar report.
https://bugs.chromium.org/p/chromium/issues/detail?id=953979

Comment 5

[Rares Doghi, Desktop QA]

Hi, I was able to reproduce this issue using the attached case on a Mac OSX using our latest Firefox Nightly (2019-04-22)

However on Windows 10 the attached example behaves entirely different, I can only scroll to the center of the pink but then scrolling stops working entirely. Might be a different issue though.

I'll set the component for this issue to Panning and Zooming, feel free to change it if there is a better suited component.

Also I did manage to do a mozregression for this issue and here are the results :

24:18.57 INFO: Last good revision: b500d17a3bf5523d70fe27d246a59ec7074cf35b
24:18.57 INFO: First bad revision: 2b8493e37c626b53fe8a3c0852573943412af809
24:18.57 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b500d17a3bf5523d70fe27d246a59ec7074cf35b&tochange=2b8493e37c626b53fe8a3c0852573943412af809

It seems that Bug 1531228 caused the behavior changes.

Comment 6

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

I can repro on macOS nightly as well. Hiro, do you have a macOS or other device you can try on?

Comment 7

[Hiroyuki Ikezoe (:hiro)]

No, I don't have any MacOS machines.

Just to confirm, the problem you guys are seeing is whether

1. Generate implicit snap positions at the scroll start/end points
2. Snap to the opposite direction

which one?

I think 2) will be fixed by bug 1546057 (landed now). And 1) is a spec issue, I think.

Comment 8

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

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

1. Generate implicit snap positions at the scroll start/end points
2. Snap to the opposite direction

which one?

I think (at least in the Apr 26 nightly, which should have the fix you referenced) the problem is #2. I'm not totally sure of the expected behaviour though since I haven't read the new snapping spec, but at least on the attached test page in the latest nightly, if I fling the bottom box hard in one direction, it will scroll all the way to the end, then "bounce" and scroll all the way to the other end and snap there. Which seems very wrong.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #8)

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

1. Generate implicit snap positions at the scroll start/end points
2. Snap to the opposite direction

which one?

I think (at least in the Apr 26 nightly, which should have the fix you referenced) the problem is #2. I'm not totally sure of the expected behaviour though since I haven't read the new snapping spec, but at least on the attached test page in the latest nightly, if I fling the bottom box hard in one direction, it will scroll all the way to the end, then "bounce" and scroll all the way to the other end and snap there. Which seems very wrong.

Hmm, I can't reproduce it on my Android phone at all, but it sounds a real issue that I am not aware of.

Comment 10

[jonjohnjohnson]

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

Hmm, I can't reproduce it on my Android phone at all, but it sounds a real issue that I am not aware of.

I can back up what [e-mail] describes is actually what I originally was trying to show about "problem #2".

"fling the bottom box hard in one direction, it will scroll all the way to the end, then "bounce" and scroll all the way to the other end and snap there. Which seems very wrong."

This is what I was referring to in my original filings "tangiential" issue.

Comment 11

[jonjohnjohnson]

Cameron McCormack (:heycam) I'd implore you to reconsider the priority for at least the "snap to the opposite direction" part of this issue, even if you want to hold off on the "implicit" snap alignments part.

Or pull it out into it's own issue.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

I had a bit of hope that bug 1547242 fixes the issue.

Can you please file a new bug for the "snap to the opposite direction" issue? I suppose the issue happens only on MacOSX.

Comment 13

[jonjohnjohnson]

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

Can you please file a new bug for the "snap to the opposite direction" issue? I suppose the issue happens only on MacOSX.

Will do – but I think I'll actually have to tweak this test case, because your work on bug 1547242 seems to have somewhat remedied osx, if not completely.

Comment 14

[jonjohnjohnson]

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

I just filed bug 1551801, it surely exhibits the buggy behavior and some in osx.

I'm wondering if the bug is reproducible for you now with the altered case?

Comment 15

[Julien Cristau [:jcristau] (back April 22)]

Woops, this was actually enabled in 68 (bug 1544136)

Comment 16

[Patricia Lawless]

heycam, (see comment 11) - is this still a p3?

Comment 17

[Hiroyuki Ikezoe (:hiro)]

The issue in question in comment 11 was split to bug 1551801. (And it's marked as P2 for now)

Comment 18

[jonjohnjohnson]

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

The issue in question in comment 11 was split to bug 1551801. (And it's marked as P2 for now)

Recent Nightly, I think because of changes in the related issues/fixes, have made this issue more complex. :/

Though gecko still doesn't seem to try and to make "implicit" snap positions at the scroll boundaries, witnessed on mac when using two finger scrolling on a trackpad, you can scroll back up to the top of the scroll container and end the gesture without any fling/momentum, seeing the snap alignment resolve back to the center of the pink block in the test case.

But, now, if you do that same trackpad two finger scroll to the top boundary, while ending the gesture with a fling/momentum, the you can have the scroll container "resolve" at that top boundary, i.e. a scroll position of 0.

This seems surely like a bug in your minds, but I did just file https://github.com/w3c/csswg-drafts/issues/4037 to clear up the csswg intentions on implicit scroll boundary snap positions.

heycam/hiro?

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Happy to take a patch for 70 but since this is triaged and set to P3 priority I'm setting it as fix-optional.
That will remove the bug from weekly regression triage.

Hiro, Is there anything else to file from jonjohnjohnson's comment 18?

Comment 20

[Hiroyuki Ikezoe (:hiro)]

Closing as per https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-701499402