Scrolling stops working in an intrinsically sized, max-height constrained scroll container when the content forces a relayout
Reported by
crh0...@gmail.com,
Aug 28
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15 Steps to reproduce the problem: I don't know if a similar thing happens in flexbox, but it definitely happens in CSS grid items. You need: 1. A "scroller" div that has overflow: auto 2. Some JS that updates the scroller div's content while it scrolls, but does not change the calculated "scrollHeight" (what web devs often do when implementing "virtual" scrolling). The scroll height total is > 100px 3. The scroller div is in a grid container with max-height: 100px and a `minmax(0, 1fr)` track that takes up the max-height. Drag the scrollbar or use mouse/touchpad scrolling. It starts to scroll initially but seems to stop when the content is updated. What is the expected behavior? The scrolling should continue (this is the behavior in Firefox, Safari) What went wrong? Scrolling stops when content is updated Did this work before? N/A Does this work in other browsers? Yes Chrome version: 68.0.3440.106 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.13.4 Flash Version: 30.0.0.154 /Users/caleb/Library/Application Support/Google/Chrome/PepperFlash/30.0.0.154/PepperFlashPlayer.plugin If you put the scroller underneath the body with a definite height, the changing contents don't break scrolling. Oddly, if you add `max-height: 100vh` to the scroller that also fixes it. Reading the CSS grid spec I don't think these tracks should be affected by content, but I guess the content changes are triggering a relayout somewhere in the grid that is interrupting scrolling.
,
Aug 29
,
Aug 30
I have a hard time reproducing it with touchpad scrolling but the provided test case repros when I try to drag the scrollbar.
,
Sep 4
I make a example for this on jsfiddle. https://jsfiddle.net/d485x16f/ I suspect this issue is realted with scroll anchoring restoration in max-height calculation logic. I tried did some changes to css: 1. change `grid-template: 1fr / 1fr` to `grid-template: 100px / 1fr` giving the grid row 100px height. makes it scrolls as expected. 2. change `max-height: 100px` to `height: 100px` giving the grid 100px height. makes it scrolls as expected. 3. add `max-height: 100vh` to #scroll as descriptation. makes it scrolls but can not reach the end of the scroller. 4. add `max-height: 100px` or `height: 100px` to #scroll. makes it scrolls as expected.
,
Sep 11
Have you confirmed the issue comes from scroll anchoring? If that's the case, you can use CSS to disable anchoring: https://drafts.csswg.org/css-scroll-anchoring/#exclusion-api
,
Sep 11
Just tried `overflow-anchor: none` and it doesn't seem to have any effect. Also with the latest Chrome it never shows the scrollbar overlays (on macOS). If I turn the scrollbars into classic mode, it just stays at the top no matter what (but does fire scroll events). Looks like it just resets the scroll to the top on each update, or something. Chrome 68 didn't have this behavior.
,
Sep 13
Just tested this issue on Dev channel (70.0.3538.16). And it fixed.
,
Sep 13
It can scroll by mouse wheel, but still have issue for dragging.
,
Sep 18
This issue is because GridTrackSizingAlgorithmStrategy::LogicalHeightForChild calls child (#scroll) layout. In #scroll layout LayoutBlockFlow::UpdateBlockLayout, unconstrained_height is 3000 which not include the max-height from #grid, then we destroy scrollbar. At the following layout, the max-height apply back to #scroll then we create a new scrollbar. So in the test page, we drag the scrollbar then the scrollbar destroyed after that a new scrollbar created. It seems we should always include max-height in unconstrained_height calcultion if we can not do that we should not destroy scrollbar in that layout.
,
Sep 19
Thanks for finding the root cause! This sounds like an issue the layout team is best equipped to fix. The repro in #5 works correctly in Firefox.
,
Sep 25
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by vamshi.kommuri@chromium.org
, Aug 29