Bug 236312

Summary: Rapid changes in scroll position can cause JS-exposed scroll offsets to be stale
Product: WebKit Reporter: Jack Doyle <jack>
Component: ScrollingAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Major CC: hi, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 15   
Hardware: iPhone / iPad   
OS: Unspecified   
Attachments:
Description Flags
Testcase none

Jack Doyle
Reported 2022-02-08 10:18:41 PST
Set the scroll position via JavaScript and then immediately check it and it seems to work correctly but under heavy load it actually REVERTS to a previous scroll position on the next requestAnimationFrame()! From what I can tell, it's definitely a bug. Here is the proof (you must run this on iOS Safari in the /debug/ window of CodePen so that it's not in an iframe): https://codepen.io/GreenSock/pen/16c435b12ef09c38125204818e7b45fc?editors=0010 Again, this only happens under heavy load. I understand JS runs on a separate thread from scrolling but all of this is happening in JS world so the regression of the scroll position doesn't make sense to me. Can anyone explain why this is happening and how we can work around it?
Attachments
Testcase (2.21 KB, text/html)
2022-02-15 14:44 PST, Sam Sneddon [:gsnedders]
no flags
Radar WebKit Bug Importer
Comment 1 2022-02-14 19:54:25 PST
Sam Sneddon [:gsnedders]
Comment 2 2022-02-15 14:44:11 PST
Created attachment 452091 [details] Testcase I couldn't get the codepen to load in debug mode, so here's it attached. <rdar://88342742>
Simon Fraser (smfr)
Comment 3 2022-02-15 15:22:00 PST
Scrolling on iOS involves an asynchronous round-trip to a different process, and it's possible we're getting a stale scroll position back to JS because of that. I don't know of any workarounds currently.
Cassie Evans
Comment 4 2023-02-23 05:50:51 PST
Are there any intentions to look into this?
Note You need to log in before you can comment on or make changes to this bug.