RESOLVED FIXED 173887
[css-scroll-snap] Triggering a layout during scroll causes jittery scrolling on iOS
https://bugs.webkit.org/show_bug.cgi?id=173887
Summary [css-scroll-snap] Triggering a layout during scroll causes jittery scrolling ...
Jürg Lehni
Reported 2017-06-27 14:20:57 PDT
I am trying to get scroll-snap to work on the body element in iOS, so that the navigation bar is allowed to disappear when the user scrolls the website, all while supporting scroll-snapping to snap to full pages. This works well as long as I don't add an overlay element with changing content that is always visible using `position: fixed;` styling. Here a test-case that illustrates the faulty behavior on iOS: https://safari-scroll-snap-bug.netlify.com On Safari / macOS and on other browsers, this behaves as it should. On iOS, I see this faulty behavior that leads to an uncontrollable website and excessive flickering sometimes: https://safari-scroll-snap-bug.netlify.com/video.mp4 It looks as if the changes in the `#overlay` element are triggering a reflow in the `body`, which then confused the scroll snap behavior. This is surprising, as it has `position: fixed;` set and changes in it should not affect the layout underneath. Another possible factor could be the changing view height due to the disappearing navigation bars. But once I add the `display: none;` to the `#overlay` element, the scroll behaves as it should. The only workaround I could find so far is setting `overflow: hidden` on `body` and having `.pages` scroll instead, but this in turn breaks the hiding of navigation bars on iOS, which is not desirable. I am hopeful that this information will assist with a timely fix of this bug.
Attachments
Test case (1.15 KB, text/html)
2021-06-24 02:48 PDT, Martin Robinson
no flags
Patch (12.58 KB, patch)
2021-07-05 08:00 PDT, Martin Robinson
no flags
Patch (12.58 KB, patch)
2021-10-18 00:08 PDT, Martin Robinson
no flags
Wenson Hsieh
Comment 1 2017-06-27 15:22:27 PDT
It's trying to scroll to its last active snap offset, which is updated after performing layout. I think we need to heavily refactor this code -- it's the cause of a lot of other similar bugs too, such as mainframe programmatic scrolling broken on iOS when scroll snapping is active.
Jürg Lehni
Comment 2 2017-06-29 06:32:52 PDT
Could anybody confirm that this is still the case in iOS 11?
Radar WebKit Bug Importer
Comment 3 2020-08-15 15:21:29 PDT
Simon Fraser (smfr)
Comment 4 2020-08-16 18:34:25 PDT
Possibly fixed by bug 214159.
Simon Fraser (smfr)
Comment 5 2020-08-16 18:34:49 PDT
Or bug 214627, the iOS equivalent.
Martin Robinson
Comment 6 2021-06-24 02:48:11 PDT
Created attachment 432146 [details] Test case It seems this is still an issue and also an issue on MacOS if you drag the scrollbar. I think we need to do two things here: * Wait to do reshaping until all the mouse buttons are up in the scrollbar. * Ensure that ScrollableArea::isUserScrollInProgress returns true when dragging the scroll view in iOS. This seems to work properly on MacOS when using the wheel.
Martin Robinson
Comment 7 2021-06-29 01:49:29 PDT
I have filed bug 227478 for the MacOS version of this issue. The issues are related, but the fixes will be different for each.
Martin Robinson
Comment 8 2021-07-05 08:00:46 PDT
Martin Robinson
Comment 9 2021-10-18 00:08:24 PDT
EWS
Comment 10 2021-10-19 06:46:47 PDT
Committed r284448 (243208@main): <https://commits.webkit.org/243208@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 441563 [details].
Note You need to log in before you can comment on or make changes to this bug.