Bug 176458
| Summary: | overflow scroll inside a grid item gets scroll offset reset to 0 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ashley Gullen <ashley> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bfulgham, jfernandez, rego, simon.fraser, svillar, webkit-bug-importer, wenson_hsieh, zalan |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Mac | ||
| OS: | macOS 10.13 | ||
Ashley Gullen
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
Note tested on macOS 10.13 beta 9, and reproduces on both Safari 11 and Safari Technology Preview 38.
Radar WebKit Bug Importer
<rdar://problem/34291577>
Simon Fraser (smfr)
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)
Oddly the bug doesn't happen if the window is not active. I suspect something in the content is triggering this.
Simon Fraser (smfr)
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
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)
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
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.