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 |
Description
Ashley Gullen
2017-09-06 08:35:03 PDT
Note tested on macOS 10.13 beta 9, and reproduces on both Safari 11 and Safari Technology Preview 38. 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. Oddly the bug doesn't happen if the window is not active. I suspect something in the content is triggering this. 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. 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. 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. 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. |