NEW 176458
overflow scroll inside a grid item gets scroll offset reset to 0 
https://bugs.webkit.org/show_bug.cgi?id=176458
Summary overflow scroll inside a grid item gets scroll offset reset to 0
Ashley Gullen
Reported 2017-09-06 08:35:03 PDT
We are developing Construct 3, a game development IDE in the browser. We have found that in one case scrolling with the trackpad in Safari keeps causing a spurious scroll event to Y = 0 (so it jumps back to the top). Trackpad scrolling happens normally until the momentum scrolling comes to a rest, and then the spurious scroll happens. To reproduce: 1) Visit https://editor.construct.net/?skip-support-check 2) Click "New project" 3) Click "Create" 4) The main view is probably all grey because it's scrolled to the top. Try scrolling down. You should see a white area come in to view. 5) Stop scrolling and let the momentum scroll come to a rest. Expected result: view remains where it is Observed result: view scrolls back to top This does not reproduce in Chrome or Firefox. I've tried to find a way to work around it, but it happens so much that ignoring scroll events to Y=0 completely blocks the ability to scroll. This bug will block us from supporting Safari with our PWA.
Attachments
Add attachment proposed patch, testcase, etc.
Ashley Gullen
Comment 1 2017-09-06 08:35:54 PDT
Note tested on macOS 10.13 beta 9, and reproduces on both Safari 11 and Safari Technology Preview 38.
Radar WebKit Bug Importer
Comment 2 2017-09-06 14:43:44 PDT
<rdar://problem/34291577>
Simon Fraser (smfr)
Comment 3 2017-09-06 17:17:45 PDT
This isn't triggered by a spurious scroll event; it's the post-scrolling layout that for some reason clamps the max Y scroll offset to 0.
Simon Fraser (smfr)
Comment 4 2017-09-06 17:25:13 PDT
Oddly the bug doesn't happen if the window is not active. I suspect something in the content is triggering this.
Simon Fraser (smfr)
Comment 5 2017-09-06 17:39:58 PDT
This seems to be triggers by grid sizing code; I suspect it's doing 2 layouts with different size constraints, and one of those layouts triggers the scroll to 0 behavior.
Ashley Gullen
Comment 6 2017-09-07 10:46:39 PDT
I did find a workaround: call preventDefault() on wheel events, manually offset the scroll position, and ignore scroll events with a Y of 0. This works but has non-native behavior (no longer axis-locks like native trackpad scrolling does). This means this bug doesn't block us any more, but obviously it'd be nice to have it fixed so we can remove the hack.
Simon Fraser (smfr)
Comment 7 2017-09-07 10:51:26 PDT
I don't get how that workaround can work. Doesn't the scroll offset get reset to 0 any time layout happens (e.g. on window resize)? I can't get the content to stick at a non-zero scroll position even when not using a trackpad to scroll.
Ashley Gullen
Comment 8 2017-09-07 14:48:16 PDT
Well in this case the main view is actually rendered with a canvas. We can store the scroll position separately and basically ignore the browser-provided scroll position, making the scroll position write-only. If the scrollbars were visible they'd probably show the wrong position, but on macOS they're invisible so we get away with it.
Note You need to log in before you can comment on or make changes to this bug.