[css-position] Clarify whether sticky-positioned elements' residual position can cause scrollbars to remain, when a tall thing is removed

[dholbert]

(Spec reference: https://drafts.csswg.org/css-position/#sticky-pos )

tl;dr: When a sticky-positioned thing with "top:0" is visible within a scrolled-down scrollable element, and then the scrollable overflow area is shrunk such that scrollbars are no longer technically necessary: should the sticky positioned element (which was positioned at a nonzero sticky-offset to remain visible) remain at the same position within the scrolled element, and continue to "prop up" the scrollable element's scroll position?

More Details:
Consider this testcase:
https://bugzilla.mozilla.org/attachment.cgi?id=8979827

This testcase has a fixed-height scrollable element (height: 200px), which contains:
(1) a tall element (height: 500px) which creates 300px of overflow (and hence, scrollbars)
(2) a sticky-positioned element that has top:0;height:100%.

When the page is loaded, the scrollable area is scrolled to the end (scrollTop=300).

Then, after a short delay, the tall element is removed, so that *nothing is causing overflow in the scrollable area anymore, besides the sticky-positioned element. (This sticky element doesn't have to create overflow, but it kind of still does, by virtue of having a residual sticky position, and because the scrollbar hasn't been moved since it got this sticky position.)

At that point, what should happen?

• Safari resets the scrollable element to scrollTop=0.
• Edge and Chrome all leave the scrollable element at the same scrolled position, despite the fact that there's no longer any tall children creating the need for it to be scrollable. (The sticky-positioned child is left at its residual position in the container's overflow area, and is left as the thing "propping up" the scrollbar, so to speak.)
• Firefox is a bit schizophrenic -- it agrees with Chrome and Edge on this testcase, but agrees with Safari on variants where the sticky-positioned thing is 1px smaller.

I don't think the spec really makes it clear which behavior is correct right now, so I'm not sure which behavior is correct & in which direction we should resolve Firefox's schizophrenic behavior. Could the spec be clarified on this point?

[dholbert]

The current spec text seems to be written from the perspective of "how do I determine the sticky position, given static content and dynamic changes to the scrollbar position". But I don't think it says how (or whether) to update the sticky position when an element is removed from the page, when that element happens to be the thing that was propping up the scrollable area and indirectly imposing a sticky position.

Also worth noting: Chrome is a bit schizophrenic here as well -- it has a scrollbar at first for both testcases, BUT if I resize the browser-window horizontally, then it immediately drops the scrollbar and resets scrollTop to 0 on the scrollable area. I've filed a Chrome bug for that inconsistency.

[emilio]

https://bugzilla.mozilla.org/show_bug.cgi?id=1585254 is the opposite of this bug, where a position: sticky thing is expected to create overflow.

[foolip]

There's a tentative test in web-platform-tests which links to this issue:
https://github.com/web-platform-tests/wpt/blob/1ebd2941a1/css/css-position/sticky/position-sticky-large-top-2.tentative.html

Chrome, Firefox and Safari all pass the test. I haven't dug into the details here, but does that fact help at all to resolve what should be done with this issue?

Since https://bugs.chromium.org/p/chromium/issues/detail?id=853829 remains open I presume that other tests could be written that fail only in Chrome, but which would also have to be tentative due to this issue?