Bug 173887 – [css-scroll-snap] Triggering a layout during scroll causes jittery scrolling on iOS

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Jürg Lehni]

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.

[Wenson Hsieh]

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]

Could anybody confirm that this is still the case in iOS 11?

[Radar WebKit Bug Importer]

<rdar://problem/67153673>

[Simon Fraser (smfr)]

Possibly fixed by bug 214159.

[Simon Fraser (smfr)]

Or bug 214627, the iOS equivalent.

[Martin Robinson]

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]

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]

Created attachment 432886 [details]
Patch

[Martin Robinson]

Created attachment 441563 [details]
Patch

[EWS]

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].