Scroll bar frozen when changing contents of div
Categories
(Core :: Layout: Scrolling and Overflow, defect, P3)
Tracking
()
People
(Reporter: raul.mihaila, Unassigned)
Details
Attachments
(1 file)
|
620 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Steps to reproduce:
Basically I have a scrollable div with some content. I scroll to the bottom of the div and update the content of the div. The scrollbar freezes meaning that when trying to scroll up it doesn't work. I reproduced this on Windows 10 and Ubuntu. In Windows where the scrollbar has arrow buttons you can see that the arrow up button doesn't work even though the scrolling should be visible, since the content is not so large (there is a child div with a height set to 1035 px). If you use the bar itself to scroll and try really hard to scroll up at some point it starts working. I attached an html file with an example. There is a button on the page, if you click it, it will scroll to the bottom of the div and change the content automatically. I'm also pasting it here.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
</head>
<body>
<button onclick="doit()">do it</button>
<div id="theDivParent"
style="position:relative;height:170px;overflow:auto;border:1px solid #000;">
<div
style="position:sticky;top:0;height:100%;">
<div>string</div>
</div>
<div id="theDiv" style="position:absolute;top:0;left:0;width:100%;height:100000px;">
</div>
</div>
<script>
function doit() {
theDivParent.scrollTop = theDivParent.scrollHeight;
theDiv.style.height = "1035px";
}
</script>
</body>
</html>
Actual results:
Scrollbar froze.
Expected results:
Scrollbar shouldn't have frozen.
|
||
Comment 1•6 years ago
|
||
Hi, I can reproduce this on the latest builds from all channels.
Thanks for reporting!
|
||
Comment 2•6 years ago
|
||
I can reproduce in a build from 2017-01-01, too (Nightly 53). So, not a regression (or not a recent one).
|
|
||
Updated•6 years ago
|
|
|
||
Comment 3•6 years ago
|
||
Also: technically the scrollbar isn't frozen -- I was able to eventually make it move after scrolling for a really long time. It's just offset by quite a lot (i.e. the scrollable region is way "over-scrolled" beyond where it should be).
You can see this in a Firefox debug build by looking at a frametree dump -- here's the inner scrolled frame after I click the do it button:
Block(div)(3) [...] {60,-5989740,59640,10200} vis-overflow={0,0,59640,6000000} scr-overflow={0,0,59640,6000000} [cs=7ff784d02c58:-moz-scrolled-content]<
line 7ff784cf4c48: [...] scr-overflow=0,0,59640,6000000 <
Block(div)(1) [...] {0,5989800,59640,10200} normal-position={0,0} [state=0000022000100210] [content=7ff784cf8700] [cs=7ff784d022f8]<
Note the overflow area being 6000000 app-units tall there (that's 100,000px), and the y=-5989740 on the scrolled frame there (the outermost rect that I'm showing) -- that means it's scrolled down by 99829px, despite the fact that we don't have that much content anymore. And note the giant "y" value on the sticky-positioned frame (the innermost frame in this frame dump)
If click the scrollable area and press home (scrolling to the top) and then do a frametree dump again, then all of these giant values reduce to more reasonable-looking values.
I think basically the issue here is that we've got a sticky-positioned thing that reaches the bottom of a scrollable area, and then we remove (shrink) the thing that was creating that scrollable area, and the sticky positioned thing is paradoxically left behind as the only thing "propping up" that scrollable area.
As you scroll up, the sticky positioned thing moves with you, leaving the trailing scrollable area with nothing left in it & hence no reason for it to be scrollable. This is why the scrollbar seems snapped to the bottom while you scroll -- your scrolling does in fact cause you to scroll upwards, but you can't tell because you've got so far to go and the area you've scrolled away "disappears" as you scroll it away.
This is a duplicate of bug 1462235 (whose testcase is less severe). There's some spec ambiguity here, which is tracked in https://github.com/w3c/csswg-drafts/issues/2794
Description
•