160622 2016-08-05 17:32:09 -0700 [Scroll Snap] Scroll snap may not happen when scrollLeft is set programmatically 2024-12-03 11:49:21 -0800 1 1 1 Unclassified WebKit CSS Safari 9 All All RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=283707 InRadar P2 Critical --- 1 sriramkrish85 wenson_hsieh dvoytenko fred.wang mrobinson simon.fraser webkit-bug-importer wenson_hsieh oldest_to_newest 1218136 0 sriramkrish85 2016-08-05 17:32:09 -0700 I am trying to hide the webkit scrollbar (i cannot use display: none or visibility: hidden due to - https://bugs.webkit.org/show_bug.cgi?id=160442) When i do something like div#outer::-webkit-scrollbar { height: 0px !important; } and then in JS do outer.scrollLeft = inner1.offsetWidth; The scrollLeft is being ignored (happens in safari and not on chrome) (now this starts working fine when i set height: 0.1px) Here is my JS BIN http://jsbin.com/fiwiqo HTML ======== <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=0"/> <title>ScrollBar Safari bug</title> </head> <body> <div id="container"> <div id="outer" class="outer"> <div class="start-marker"></div> <div class="end-marker"></div> <div id="inner1" class="inner">1</div> <div id="inner2" class="inner">2</div> <div id="inner3" class="inner">3</div> </div> </div> <textarea id="log-el"></textarea> </body> </html> CSS ========= * { padding: 0; margin:0; } li { list-style-type: none; } body { background: orange; } /* AMP.CSS */ html, body { overflow-x: hidden !important; height: auto !important; } /** * Margin:0 is currently needed for iOS viewer embeds. * See: * https://github.com/ampproject/amphtml/blob/master/spec/amp-html-layout.md * and {@link ViewportBindingNaturalIosEmbed_} for more info. */ body { margin: 0 !important; } /* END AMP.CSS */ #container { width: 100vw; height: 300px; position: absolute; } #outer { background: red; box-sizing: border-box; display: flex !important; flex-wrap: nowrap; height: 100% !important; left: 0; overflow-x: auto !important; overflow-y: hidden !important; position: absolute !important; top: 0; white-space: nowrap !important; width: 100% !important; -webkit-overflow-scrolling: touch; -webkit-scroll-snap-type: mandatory; scroll-snap-type: mandatory; } .inner { background: yellow; border: solid 1px blue; font-size: 200px; display: flex !important; align-items: center !important; flex: 0 0 100% !important; height: 100% !important; justify-content: center !important; position: relative !important; -webkit-scroll-snap-coordinate: 0 0; scroll-snap-coordinate: 0 0; width: 100% !important; } .start-marker, .end-marker { background-color: transparent !important; display: block !important; flex: 0 0 1px !important; height: 100% !important; position: relative !important; -webkit-scroll-snap-coordinate: 0 0; scroll-snap-coordinate: 0 0; width: 1px !important; } .start-marker { order: -1 !important; margin-left: -1px !important; } end-marker { order: 100000000 !important; margin-right: -1px !important; } /* Let's get this party started */ div#outer::-webkit-scrollbar { height: 0px !important; } #log-el { background-color: cyan; display: block; width: 100%; height: 40vh; margin-top: 310px; } JS ======== var startTime = new Date().getTime(); function log(m) { var el = document.getElementById('log-el'); el.value = '[' + (new Date().getTime() - startTime) + '] ' + (m || '') + '\n'+ el.value; } outer.addEventListener('scroll', function(event) { log('scroll left: '+ outer.scrollLeft); }); outer.scrollLeft = inner1.offsetWidth; 1237377 1 webkit-bug-importer 2016-10-06 15:17:34 -0700 <rdar://problem/28660060> 1300953 2 308082 fred.wang 2017-04-25 03:29:44 -0700 Created attachment 308082 testcase This is a reduced testcase based on the bug description. Scrolling works as expected in Safari and iOS. However, I still see the bug on https://output.jsbin.com/fiwiqo ; it would be good to have a reduced testcase demonstrating the problem and to update the bug description accordingly. 1301111 3 sriramkrish85 2017-04-25 10:46:55 -0700 :fredw - on IOS 10.3 the JS scroll works on MY JS BIN but it fails to snap to the right point after the scroll - should i open another bug for that? 1301159 4 fred.wang 2017-04-25 12:43:06 -0700 (In reply to Sriram Krishnan from comment #3) > :fredw - on IOS 10.3 the JS scroll works on MY JS BIN but it fails to snap > to the right point after the scroll - should i open another bug for that? Yes, I'm able to reproduce the issue with your JS BIN, however the test case seems complex with many elements, css rules and javascript. Would it be possible to have a test with only the minimal code demonstrating the error (I tried attachment 308082 based on the bug description but it does not work exhibit the issue)? At worst, I can try again to write one, starting from your JS BIN rather rather than from the bug description... 1301195 5 sriramkrish85 2017-04-25 13:37:40 -0700 (In reply to Frédéric Wang (:fredw) from comment #4) > (In reply to Sriram Krishnan from comment #3) > > :fredw - on IOS 10.3 the JS scroll works on MY JS BIN but it fails to snap > > to the right point after the scroll - should i open another bug for that? > > Yes, I'm able to reproduce the issue with your JS BIN, however the test case > seems complex with many elements, css rules and javascript. Would it be > possible to have a test with only the minimal code demonstrating the error > (I tried attachment 308082 [details] based on the bug description but it > does not work exhibit the issue)? At worst, I can try again to write one, > starting from your JS BIN rather rather than from the bug description... I think the issue happens in the presence if css snap points and your test case does not seem to have it 1301208 6 wenson_hsieh 2017-04-25 13:50:25 -0700 (In reply to Sriram Krishnan from comment #5) > (In reply to Frédéric Wang (:fredw) from comment #4) > > (In reply to Sriram Krishnan from comment #3) > > > :fredw - on IOS 10.3 the JS scroll works on MY JS BIN but it fails to snap > > > to the right point after the scroll - should i open another bug for that? > > > > Yes, I'm able to reproduce the issue with your JS BIN, however the test case > > seems complex with many elements, css rules and javascript. Would it be > > possible to have a test with only the minimal code demonstrating the error > > (I tried attachment 308082 [details] based on the bug description but it > > does not work exhibit the issue)? At worst, I can try again to write one, > > starting from your JS BIN rather rather than from the bug description... > > I think the issue happens in the presence if css snap points and your test > case does not seem to have it Sriram, what is the expected vs. observed behavior in your test page? I loaded your test page on ToT WebKit on iOS. If I replace the following: `-webkit-scroll-snap-coordinate: 0 0` => `scroll-snap-align: start` `-webkit-scroll-snap-type: mandatory` => `scroll-snap-type: x mandatory` ...then scroll snapping behaves normally, and the test page loads with the box labeled "2" scrolled into view. Is this correct? 1301240 7 sriramkrish85 2017-04-25 14:24:54 -0700 (In reply to Wenson Hsieh from comment #6) > (In reply to Sriram Krishnan from comment #5) > > (In reply to Frédéric Wang (:fredw) from comment #4) > > > (In reply to Sriram Krishnan from comment #3) > > > > :fredw - on IOS 10.3 the JS scroll works on MY JS BIN but it fails to snap > > > > to the right point after the scroll - should i open another bug for that? > > > > > > Yes, I'm able to reproduce the issue with your JS BIN, however the test case > > > seems complex with many elements, css rules and javascript. Would it be > > > possible to have a test with only the minimal code demonstrating the error > > > (I tried attachment 308082 [details] based on the bug description but it > > > does not work exhibit the issue)? At worst, I can try again to write one, > > > starting from your JS BIN rather rather than from the bug description... > > > > I think the issue happens in the presence if css snap points and your test > > case does not seem to have it > > Sriram, what is the expected vs. observed behavior in your test page? > > I loaded your test page on ToT WebKit on iOS. If I replace the following: > > `-webkit-scroll-snap-coordinate: 0 0` => `scroll-snap-align: start` > `-webkit-scroll-snap-type: mandatory` => `scroll-snap-type: x mandatory` > > ...then scroll snapping behaves normally, and the test page loads with the > box labeled "2" scrolled into view. Is this correct? At ant point the box labeled 1 should be the first in view. So that is a bug, also CSS snap points are not working in when i replace as said in your comments. I put this in a JS Bin https://output.jsbin.com/xuhupof/quiet To re-clarify what works and what is broken on my initial JS bin, http://jsbin.com/fiwiqo/quiet Try scrolling the yellow container- CSS snap points work fine. Use the --> Button below the page , the container scrolls (which was not working before) but it fails to snap to the right snap point now. 1301267 8 wenson_hsieh 2017-04-25 14:51:13 -0700 > At ant point the box labeled 1 should be the first in view. So that is a > bug, also I'm not sure I understand the reasoning behind this. Are you suggesting `outer.scrollLeft = inner1.offsetWidth;` in your script should not scroll the container such that the box labeled 2 is in view? > CSS snap points are not working in when i replace as said in your > comments. > I put this in a JS Bin > https://output.jsbin.com/xuhupof/quiet > Yes, they are not working because 10.3 is still on the old version of the spec (the version that still supports the deprecated -webkit-scroll-snap-coordinates property). Unfortunately, there's no way for you to try out these new properties on ToT WebKit on iOS. > > To re-clarify what works and what is broken on my initial JS bin, > http://jsbin.com/fiwiqo/quiet > > Try scrolling the yellow container- CSS snap points work fine. > Use the --> Button below the page , the container scrolls (which was not > working before) but it fails to snap to the right snap point now. I see -- thanks for the clarification! Two questions: 1. When you wrote "fails to snap to the right snap point", do you mean that it snaps to the wrong point, or that it does not snap at all? 2. This bug seems extremely similar to <https://bugs.webkit.org/show_bug.cgi?id=170560>. Can you help me understand what the difference between these two bugs is? 1301271 9 sriramkrish85 2017-04-25 15:03:36 -0700 (In reply to Wenson Hsieh from comment #8) > > At ant point the box labeled 1 should be the first in view. So that is a > > bug, also > > I'm not sure I understand the reasoning behind this. Are you suggesting > `outer.scrollLeft = inner1.offsetWidth;` in your script should not scroll > the container such that the box labeled 2 is in view? > > > CSS snap points are not working in when i replace as said in your > > comments. > > I put this in a JS Bin > > https://output.jsbin.com/xuhupof/quiet > > > > Yes, they are not working because 10.3 is still on the old version of the > spec (the version that still supports the deprecated > -webkit-scroll-snap-coordinates property). Unfortunately, there's no way for > you to try out these new properties on ToT WebKit on iOS. > > > > > To re-clarify what works and what is broken on my initial JS bin, > > http://jsbin.com/fiwiqo/quiet > > > > Try scrolling the yellow container- CSS snap points work fine. > > Use the --> Button below the page , the container scrolls (which was not > > working before) but it fails to snap to the right snap point now. > > I see -- thanks for the clarification! Two questions: > 1. When you wrote "fails to snap to the right snap point", do you mean that > it snaps to the wrong point, or that it does not snap at all? > 2. This bug seems extremely similar to > <https://bugs.webkit.org/show_bug.cgi?id=170560>. Can you help me understand > what the difference between these two bugs is? 1. It fails to snap at all (you can try out here https://output.jsbin.com/xuhupof/quiet) 2. in https://bugs.webkit.org/show_bug.cgi?id=170560 snapping happens after scroll but offsets to a wrong snap-point , here snapping does not happen at all 1301424 10 wenson_hsieh 2017-04-25 19:42:09 -0700 (In reply to Sriram Krishnan from comment #9) > (In reply to Wenson Hsieh from comment #8) > > > At ant point the box labeled 1 should be the first in view. So that is a > > > bug, also > > > > I'm not sure I understand the reasoning behind this. Are you suggesting > > `outer.scrollLeft = inner1.offsetWidth;` in your script should not scroll > > the container such that the box labeled 2 is in view? > > > > > CSS snap points are not working in when i replace as said in your > > > comments. > > > I put this in a JS Bin > > > https://output.jsbin.com/xuhupof/quiet > > > > > > > Yes, they are not working because 10.3 is still on the old version of the > > spec (the version that still supports the deprecated > > -webkit-scroll-snap-coordinates property). Unfortunately, there's no way for > > you to try out these new properties on ToT WebKit on iOS. > > > > > > > > To re-clarify what works and what is broken on my initial JS bin, > > > http://jsbin.com/fiwiqo/quiet > > > > > > Try scrolling the yellow container- CSS snap points work fine. > > > Use the --> Button below the page , the container scrolls (which was not > > > working before) but it fails to snap to the right snap point now. > > > > I see -- thanks for the clarification! Two questions: > > 1. When you wrote "fails to snap to the right snap point", do you mean that > > it snaps to the wrong point, or that it does not snap at all? > > 2. This bug seems extremely similar to > > <https://bugs.webkit.org/show_bug.cgi?id=170560>. Can you help me understand > > what the difference between these two bugs is? > > > 1. It fails to snap at all (you can try out here > https://output.jsbin.com/xuhupof/quiet) Is this a regression? If so, on what version of iOS was it working before? > > 2. in https://bugs.webkit.org/show_bug.cgi?id=170560 snapping happens after > scroll but offsets to a wrong snap-point , here snapping does not happen at > all Regarding https://output.jsbin.com/xuhupof: Since you are on iOS10.3, specifying scroll-snap-type: x mandatory; will not work, since we don't support the new scroll snapping properties there. You'll have to use -webkit-scroll- snap-type: mandatory. It looks like the JS bin badge at the top right fading in and out is causing a layout to happen, which prompts WebKit to immediately scroll to the active snap offset (i.e. the nearest offset). 1301474 11 sriramkrish85 2017-04-25 21:36:44 -0700 (In reply to Wenson Hsieh from comment #10) > (In reply to Sriram Krishnan from comment #9) > > (In reply to Wenson Hsieh from comment #8) > > > > At ant point the box labeled 1 should be the first in view. So that is a > > > > bug, also > > > > > > I'm not sure I understand the reasoning behind this. Are you suggesting > > > `outer.scrollLeft = inner1.offsetWidth;` in your script should not scroll > > > the container such that the box labeled 2 is in view? > > > > > > > CSS snap points are not working in when i replace as said in your > > > > comments. > > > > I put this in a JS Bin > > > > https://output.jsbin.com/xuhupof/quiet > > > > > > > > > > Yes, they are not working because 10.3 is still on the old version of the > > > spec (the version that still supports the deprecated > > > -webkit-scroll-snap-coordinates property). Unfortunately, there's no way for > > > you to try out these new properties on ToT WebKit on iOS. > > > > > > > > > > > To re-clarify what works and what is broken on my initial JS bin, > > > > http://jsbin.com/fiwiqo/quiet > > > > > > > > Try scrolling the yellow container- CSS snap points work fine. > > > > Use the --> Button below the page , the container scrolls (which was not > > > > working before) but it fails to snap to the right snap point now. > > > > > > I see -- thanks for the clarification! Two questions: > > > 1. When you wrote "fails to snap to the right snap point", do you mean that > > > it snaps to the wrong point, or that it does not snap at all? > > > 2. This bug seems extremely similar to > > > <https://bugs.webkit.org/show_bug.cgi?id=170560>. Can you help me understand > > > what the difference between these two bugs is? > > > > > > 1. It fails to snap at all (you can try out here > > https://output.jsbin.com/xuhupof/quiet) > > Is this a regression? If so, on what version of iOS was it working before? > That is the spec and it is expected to work like that :) not sure if this is a regression > > > > 2. in https://bugs.webkit.org/show_bug.cgi?id=170560 snapping happens after > > scroll but offsets to a wrong snap-point , here snapping does not happen at > > all > > Regarding https://output.jsbin.com/xuhupof: > > Since you are on iOS10.3, specifying scroll-snap-type: x mandatory; will not > work, since we > don't support the new scroll snapping properties there. You'll have to use > -webkit-scroll- > snap-type: mandatory. > > It looks like the JS bin badge at the top right fading in and out is causing > a layout to > happen, which prompts WebKit to immediately scroll to the active snap offset > (i.e. the > nearest offset). https://output.jsbin.com/xuhupof/quiet - should not have the jsbin badge , the old scroll properties are working perfectly fine Pasting my comments from above -- To re-clarify what works and what is broken on my initial JS bin, http://jsbin.com/fiwiqo/quiet Try scrolling the yellow container- CSS snap points work fine. Use the --> Button below the page , the container scrolls (which was not working before) but it fails to snap to the right snap point now. 1301519 12 fred.wang 2017-04-26 00:00:07 -0700 (In reply to Sriram Krishnan from comment #5) > I think the issue happens in the presence if css snap points and your test > case does not seem to have it Ah, OK. I understood you were doing the snapping yourself by setting the scrollLeft. I'll upload a new testcase. 1301530 13 308228 fred.wang 2017-04-26 00:21:45 -0700 Created attachment 308228 testcase Sriram: So this is a new test case with CSS snap points. The scrollTop is set to move nearer to the green box than to the red box and the expectation would be that it will automatically snap to the green box, is that correct? If the user scrolls the #div1 in iOS ToT, the snapping happens correctly. However it fails when the scrollTop is set programmatically. #div2 is similar with a CSS syntax that works in Gecko. I see the same behavior: snapping happens when the user scrolls the div but fails when done programmatically. I tried to use a fixed div as in bug 170560 to force a reflow, but that did not change anything. 1303234 14 fred.wang 2017-05-01 08:13:22 -0700 > Try scrolling the yellow container- CSS snap points work fine. The behavior when the user scrolls the yellow container is clear to me: the CSS snapping happens immediately after the scrolling end (mouse released on Desktop or "momentum" slowed down to zero speed on iOS). > Use the --> Button below the page , the container scrolls (which was not working before) but it fails to snap to the right snap point now. It is not clear to me when the CSS snapping should happen after a programmatic change? On the one hand, if it's just after setting the value then clicking "-->" will move the container somewhere between [1] and [2] and immediately go snap to [1] (assuming the move done by one clock is small, as in your demo). This seems to be the https://bugs.webkit.org/show_bug.cgi?id=170560 and what prevented the scrolling in the past. On the other hand, if it's not set immediately then I don't see how you can do the snapping without forcing a relayout yourself. This is what the JSBIN badge is doing in your demo. > That is the spec and it is expected to work like that :) Are you able to indicate which part of the specification clarify my doubt regarding snapping after programmatic change? It's possible that the behavior is unclear and an issue should be reported to the spec authors. Are you testing this on other platforms / browsers? What is the behavior there? 1401117 15 334383 fred.wang 2018-02-21 08:40:05 -0800 Created attachment 334383 Another testcase This is a simple testcase without -webkit prefixes and using the new values described in the latest Working Draft (https://drafts.csswg.org/css-scroll-snap/). The snapping happens when doing user scrolling with the iOS simulator (both the latest release and trunk) but not when doing programmatic scrolling. Chrome Canary (with experimental web platform features enabled) behaves the same. 1401145 16 fred.wang 2018-02-21 10:11:03 -0800 @Sriram: Concretely using attachment 334383, what would be the expected behavior for you if you click several times the "Down" button to perform programmatic scrolling? I understand that: * Snapping should happen. * It should not happen for the first point (otherwise you are stuck) * It should happen for the second point... but should that happen immediately (after the first move) or once we have passed half the distance between the first and second point? * Once we snapped to the second point and continue to use the "Down" button then things start again from that point (we don't snap to the second point but to the third one) and so on for other points. As I said, I tested in the latest versions of WebKit and Chrome Canary and snapping does not happen at all for programmatic scrolling. Which platform do you use to get the behavior you want? I also read https://drafts.csswg.org/css-scroll-snap/#snap-concepts and it does not seem to say anything against snapping for programmatic scrolling. It is also a bit flexible/unclear about the exact implementation. It has an explanation for escaping the initial snap position that we could use as long as we claim that the initial programmatic move is not a "fairly small distance" 'User agents must ensure that a user can “escape” a snap position, regardless of the scroll method. For example, if the snap type is mandatory and the next snap position is more than two screen-widths away, a naïve “always snap to nearest” selection algorithm might “trap” the user if their end position was only one screen-width away. Instead, a smarter algorithm that only returned to the starting snap position if the end-point was a fairly small distance from it, and otherwise ignored the starting snap position, would give better behavior. (This implies that a scroll with only an intended direction must always ignore the starting snap positions.)' Note that for programmatic scroll with an intended direction (scrollBy), scrolling may be animated and hence interpreted like a user scroll. However, this does not correspond to the initial description of this bug which uses something like scrollLeft += 100. 1411067 17 fred.wang 2018-04-02 06:48:28 -0700 Updating the title per comment 11 1413935 18 fred.wang 2018-04-11 23:05:23 -0700 According to some AMP developers, this bug looks fixed in iOS 11.3. Moreover Blink and iOS now behave the same for attachment 334383. Hence I'm closing this bug. I understand that there is a use case with scroll snap and programmatic scrolling, but the spec does not seem very clear regarding when the snapping should happen exactly (see comment 16). Incidentally, this is not only for programmatic scrolling since one could replace the "scrollBy(...)" or "scrollLeft/Top += ..." Javascript calls with arrow keys to scroll the content. Probably, a new bug should be opened when the spec is clarified and we have an obvious spec violation or browser incompatibility. 308082 2017-04-25 03:29:44 -0700 2017-04-26 00:21:45 -0700 testcase 160622.html text/html 932 fred.wang PCFET0NUWVBFIGh0bWw+CjxoZWFkPgogIDxtZXRhIGNoYXJzZXQ9InV0Zi04Ij4KICA8dGl0bGU+ V2ViS2l0IEJ1ZyAxNjA2MjI8L3RpdGxlPgogIDxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50 PSJ3aWR0aD1kZXZpY2Utd2lkdGgiPgogIDxzdHlsZT4KICAgICNkaXYxLCAjZGl2MiB7CiAgICAg IGJhY2tncm91bmQ6IGdyYXk7CiAgICAgIHdpZHRoOiAyMDBweDsKICAgICAgaGVpZ2h0OiAyMDBw eDsKICAgICAgb3ZlcmZsb3cteDogYXV0bzsKICAgICAgLXdlYmtpdC1vdmVyZmxvdy1zY3JvbGxp bmc6IHRvdWNoOwogICAgfQogICAgI2RpdjI6Oi13ZWJraXQtc2Nyb2xsYmFyIHsKICAgICAgaGVp Z2h0OiAwcHg7CiAgICB9CiAgICAuZ3JhZGllbnQgewogICAgICB3aWR0aDogNTAwMHB4OwogICAg ICBoZWlnaHQ6IDEwMHB4OwogICAgICBiYWNrZ3JvdW5kOiBsaW5lYXItZ3JhZGllbnQoMTM1ZGVn LCByZWQsIGdyZWVuKTsKICAgIH0KICA8L3N0eWxlPgogIDxzY3JpcHQ+CiAgICB3aW5kb3cuYWRk RXZlbnRMaXN0ZW5lcigibG9hZCIsIGZ1bmN0aW9uKCkgewogICAgICBkb2N1bWVudC5nZXRFbGVt ZW50QnlJZCgiZGl2MSIpLnNjcm9sbExlZnQgPSA1MDAwOwogICAgICBkb2N1bWVudC5nZXRFbGVt ZW50QnlJZCgiZGl2MiIpLnNjcm9sbExlZnQgPSA1MDAwOwogICAgfSk7CiAgPC9zY3JpcHQ+Cjwv aGVhZD4KPGJvZHk+CiAgPGRpdj4KICAgIERlZmF1bHQKICAgIDxkaXYgaWQ9ImRpdjEiPgogICAg ICA8ZGl2IGNsYXNzPSJncmFkaWVudCI+PC9kaXY+CiAgICA8L2Rpdj4KICA8L2Rpdj4KICA8aHIv PgogIDxkaXY+CiAgICA6Oi13ZWJraXQtc2Nyb2xsYmFyIHsgaGVpZ2h0OiAwcHg7IH0KICAgIDxk aXYgaWQ9ImRpdjIiPgogICAgICA8ZGl2IGNsYXNzPSJncmFkaWVudCI+PC9kaXY+CiAgICA8L2Rp dj4KICA8L2Rpdj4KPC9ib2R5Pgo= 308228 2017-04-26 00:21:45 -0700 2017-04-26 00:21:45 -0700 testcase 160622.html text/html 1217 fred.wang PCFET0NUWVBFIGh0bWw+CjxoZWFkPgogIDxtZXRhIGNoYXJzZXQ9InV0Zi04Ij4KICA8dGl0bGU+ V2ViS2l0IEJ1ZyAxNjA2MjI8L3RpdGxlPgogIDxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50 PSJ3aWR0aD1kZXZpY2Utd2lkdGgiPgogIDxzdHlsZT4KICAgICNkaXYxLCAjZGl2MiB7CiAgICAg IGJhY2tncm91bmQ6IGdyYXk7CiAgICAgIHdpZHRoOiAzMDBweDsKICAgICAgaGVpZ2h0OiAyMDBw eDsKICAgICAgb3ZlcmZsb3cteTogYXV0bzsKICAgICAgLXdlYmtpdC1vdmVyZmxvdy1zY3JvbGxp bmc6IHRvdWNoOwogICAgfQogICAgLmZhaWwsIC5wYXNzIHsKICAgICAgd2lkdGg6IDIwMHB4Owog ICAgICBoZWlnaHQ6IDIwMHB4OwogICAgfQogICAgLmZhaWwgewogICAgICBiYWNrZ3JvdW5kOiBy ZWQ7CiAgICB9CiAgICAucGFzcyB7CiAgICAgIGJhY2tncm91bmQ6IGdyZWVuOwogICAgfQoKICAg ICNkaXYxIHsKICAgICAgc2Nyb2xsLXNuYXAtdHlwZTogeSBtYW5kYXRvcnk7CiAgICB9CiAgICAj ZGl2MSA+IGRpdiB7CiAgICAgIHNjcm9sbC1zbmFwLWFsaWduOiBzdGFydDsKICAgIH0KCiAgICAj ZGl2MiB7CiAgICAgIHNjcm9sbC1zbmFwLXR5cGU6IG1hbmRhdG9yeTsKICAgICAgLXdlYmtpdC1z Y3JvbGwtc25hcC10eXBlOiBtYW5kYXRvcnk7CiAgICB9CiAgICAjZGl2MiA+IGRpdiAgIHsKICAg ICAgc2Nyb2xsLXNuYXAtY29vcmRpbmF0ZTogMCAwOwogICAgICAtd2Via2l0LXNjcm9sbC1zbmFw LWNvb3JkaW5hdGU6IDAgMDsKICAgIH0KICA8L3N0eWxlPgogIDxzY3JpcHQ+CiAgICB3aW5kb3cu YWRkRXZlbnRMaXN0ZW5lcigibG9hZCIsIGZ1bmN0aW9uKCkgewogICAgICBkb2N1bWVudC5nZXRF bGVtZW50QnlJZCgiZGl2MSIpLnNjcm9sbFRvcCA9IDE1MDsKICAgICAgZG9jdW1lbnQuZ2V0RWxl bWVudEJ5SWQoImRpdjIiKS5zY3JvbGxUb3AgPSAxNTA7CiAgICB9KTsKICA8L3NjcmlwdD4KPC9o ZWFkPgo8Ym9keT4KICA8ZGl2PgogICAgPGRpdiBpZD0iZGl2MSI+CiAgICAgIDxkaXYgY2xhc3M9 ImZhaWwiPjwvZGl2PgogICAgICA8ZGl2IGNsYXNzPSJwYXNzIj48L2Rpdj4KICAgIDwvZGl2Pgog IDwvZGl2PgogIDxoci8+CiAgPGRpdj4KICAgIDxkaXYgaWQ9ImRpdjIiPgogICAgICA8ZGl2IGNs YXNzPSJmYWlsIj48L2Rpdj4KICAgICAgPGRpdiBjbGFzcz0icGFzcyI+PC9kaXY+CiAgICA8L2Rp dj4KICA8L2Rpdj4KPC9ib2R5Pgo= 334383 2018-02-21 08:40:05 -0800 2018-02-21 08:40:05 -0800 Another testcase scroll-snapping.html text/html 1030 fred.wang PCFET0NUWVBFIGh0bWw+CjxodG1sPgogIDxoZWFkPgogICAgPHRpdGxlPlNjcm9sbCBTbmFwcGlu ZzwvdGl0bGU+CiAgICA8bWV0YSBuYW1lPSJ2aWV3cG9ydCIgY29udGVudD0id2lkdGg9ZGV2aWNl LXdpZHRoIj4KICAgIDxtZXRhIGNoYXJzZXQ9InV0Zi04Ii8+CiAgICA8c3R5bGU+CiAgICAgIGRp diB7CiAgICAgICAgd2lkdGg6IDIwMHB4OwogICAgICAgIGhlaWdodDogMjAwcHg7CiAgICAgIH0K ICAgICAgI3Njcm9sbENvbnRhaW5lciB7CiAgICAgICAgb3ZlcmZsb3cteDogaGlkZGVuOwogICAg ICAgIG92ZXJmbG93LXk6IGF1dG87CiAgICAgICAgLXdlYmtpdC1vdmVyZmxvdy1zY3JvbGxpbmc6 IHRvdWNoOwogICAgICAgIHNjcm9sbC1zbmFwLXR5cGU6IHkgbWFuZGF0b3J5OwogICAgICB9CiAg ICAgIC5zY3JvbGxDb250ZW50IHsKICAgICAgICBiYWNrZ3JvdW5kOiBsaW5lYXItZ3JhZGllbnQo MTM1ZGVnLCByZWQsIGJsdWUpOwogICAgICAgIHNjcm9sbC1zbmFwLWFsaWduOiBub25lIHN0YXJ0 OwogICAgICB9CiAgICA8L3N0eWxlPgogIDwvaGVhZD4KICA8Ym9keT4KICAgIDxkaXYgaWQ9InNj cm9sbENvbnRhaW5lciI+CiAgICAgIDxkaXYgY2xhc3M9InNjcm9sbENvbnRlbnQiPjE8L2Rpdj4K ICAgICAgPGRpdiBjbGFzcz0ic2Nyb2xsQ29udGVudCI+MjwvZGl2PgogICAgICA8ZGl2IGNsYXNz PSJzY3JvbGxDb250ZW50Ij4zPC9kaXY+CiAgICAgIDxkaXYgY2xhc3M9InNjcm9sbENvbnRlbnQi PjQ8L2Rpdj4KICAgICAgPGRpdiBjbGFzcz0ic2Nyb2xsQ29udGVudCI+NTwvZGl2PgogICAgPC9k aXY+CiAgICA8cD4KICAgICAgPGJ1dHRvbiBvbmNsaWNrPSJkb2N1bWVudC5nZXRFbGVtZW50QnlJ ZCgnc2Nyb2xsQ29udGFpbmVyJykuc2Nyb2xsQnkoMCwgLTEwKSI+VXA8L2J1dHRvbj4KICAgICAg PGJ1dHRvbiBvbmNsaWNrPSJkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnc2Nyb2xsQ29udGFpbmVy Jykuc2Nyb2xsQnkoMCwgMTApIj5Eb3duPC9idXR0b24+CiAgICA8L3A+CiAgPC9ib2R5Pgo8L2h0 bWw+Cg==