Bug 169800

Summary: After a programmatic scroll in a scroll snap container, the scroll offset jumps to the last reached snap offset
Product: WebKit Reporter: Malte Ubl <malteubl>
Component: CSSAssignee: Wenson Hsieh <wenson_hsieh>
Status: NEW ---    
Severity: Blocker CC: jonlee, simon.fraser, sriramkrish85, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: iPhone / iPad   
OS: Unspecified   
Attachments:
Description Flags
Reduced test case adapted from <http://output.jsbin.com/fiwiqo> none

Description Malte Ubl 2017-03-16 17:55:18 PDT
I'm sorry that we do not currently have a reduced repro case, but we thought you might want to know that CSS snap points are broken in Safari in current iOS 10.3 beta 2.

More details here https://github.com/ampproject/amphtml/issues/7670

The bug has a few repro URLs.

This affects a large subset of AMP pages (likely a few 100 million). We will revert to non-snap points behavior, but this will represent a signficiant regression in UX.
Comment 1 Malte Ubl 2017-03-16 18:18:58 PDT
Updated to reflect that this is still broken in beta 6.
Comment 2 Sriram Krishnan 2017-03-16 18:47:24 PDT
Here is the URL to reproduce what Malte described below

http://amphtml-nightly.herokuapp.com/test/manual/amp-slidescroll.amp.html



Videos:


Working slides on IOS 10.2- https://www.youtube.com/watch?v=DkI5U9Sqlm4

Broken slides on IOS 10.3 beta (test on beta 7) - https://www.youtube.com/watch?v=r6jZILTvt5E
Comment 3 Simon Fraser (smfr) 2017-03-16 21:41:08 PDT
The syntax changed to match the latest spec:
https://drafts.csswg.org/css-scroll-snap-1/
Comment 4 Sriram Krishnan 2017-03-16 23:36:39 PDT
@smfr - is there a date when this would come out of beta?
Comment 5 Sriram Krishnan 2017-03-21 18:20:14 PDT
Ok - Now i got clarity into what the real issue is. This is because of snap points

This is not because of the syntax change , the old syntax still works fine on the beta.
The only issue is when we set scrollLeft on the container via JS, the browser resets it back to the last known snap position set via css snapping. the right behavior would be to snap to the closest snap point.

Here is my JS BIN

http://jsbin.com/fiwiqo/61/edit?html,css,js,output

And the video demonstrating what is wrong.

https://youtu.be/r5P8d-k1Q1Y
Comment 6 Sriram Krishnan 2017-03-24 22:14:23 PDT
@Wenson Hsieh, any updates on this? will this be fixed before the beta launches?
Comment 7 Wenson Hsieh 2017-03-25 01:49:58 PDT
(In reply to Sriram Krishnan from comment #6)
> @Wenson Hsieh, any updates on this? will this be fixed before the beta
> launches?

Unfortunately, I cannot comment on what changes will make it into future releases. However, I will make it a priority to investigate and fix this problem on ToT.
Comment 8 Wenson Hsieh 2017-03-25 02:08:22 PDT
<rdar://problem/31257989>
Comment 9 Sriram Krishnan 2017-04-04 13:17:01 PDT
Any update on when this would be fixed. As Malte mentioned it affects a few 100 million (AMP) pages, it would be great to get this fixed at the earliest possible!
Comment 10 Jon Lee 2017-04-04 13:56:19 PDT
Thanks. Unfortunately, we cannot discuss release dates, but understand that this is a very important bug for AMP.
Comment 11 Wenson Hsieh 2017-04-05 14:57:23 PDT
Created attachment 306322 [details]
Reduced test case adapted from <http://output.jsbin.com/fiwiqo>
Comment 12 Sriram Krishnan 2017-05-31 15:44:57 PDT
I believe this was solved in https://bugs.webkit.org/show_bug.cgi?id=170560 - can some one correct me if i am wrong?

@Wenson Hsieh