WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Patch
(12.58 KB, patch)
2021-07-05 08:00 PDT
,
Martin Robinson
no flags
Details
Formatted Diff
Diff
Patch
(12.58 KB, patch)
2021-10-18 00:08 PDT
,
Martin Robinson
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/67153673
>
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
Created
attachment 432886
[details]
Patch
Martin Robinson
Comment 9
2021-10-18 00:08:24 PDT
Created
attachment 441563
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug