1769060 - position: sticky regression: height of sticky element child added to scroll parent

Status: REOPENED

(Core :: Layout, defect)

Description

[rash]

Attachment: ff-sticky-bug.png

Steps to reproduce:

1. Open https://jsfiddle.net/x16b2oy4/1/
2. Scroll down inside green square

Actual results:

Scroll height of #container is height of #content + height of #sticky-inner. You can see some red background, as shown in the screenshot from Firefox.

Expected results:

Scroll height of #container should be height of #content. You should not see any red background, as shown on the screenshot from Chrome.

This currently works in Chrome and Safari, and used to work in earlier versions of Firefox. Tested on Firefox 99, 100, 101.0b5.

My real use case is positioning custom scroll bars: https://buntpapier.rash.codes/directives/scrollbar.html

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1377072

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

:TYLin, since you are the author of the regressor, bug 1377072, could you take a look?
For more information, please visit auto_nag documentation.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from reporter's jsfiddle)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced)

Comment 5

[Daniel Holbert [:dholbert]]

I think this might be a Chrome/Safari bug. It's not clear to me why they're doing what they're doing.

As shown by testcase 2, we have some abspos content here -- the blue thing in the original testcase, purple-bordered-aqua in my testcase. It's the the child of a 0-sized sticky-positioned element. Chrome does not let this abspos element contribute to the scrollable overflow, for some reason.

This Chrome behavior is extremely fragile; if I make any of the following changes to my testcase 2...
(a) give #sticky a nonzero border-box-width (via e.g. width:1px or padding-left: 1px or border: 1px solid)
(b) give #sticky-inner left:0 instead of right:0
(c) change #sticky to position:relative instead of position:sticky
...then Chrome matches Firefox's behavior and draws a super tall scrollbar.

It doesn't make sense that these changes would factor into whether or not this abspos descendant causes scrollable overflow or not. And it seems pretty intuitively clear that it should cause scrollable overflow.

So I'm pretty sure this behavioral difference is a Chrome bug rather than a Firefox bug.

(Note that before bug 1377072, Firefox neglected to include the child frame's scrollable-overflow in this scenario, which happened to match Chrome's behavior on this particular testcase, though it was clearly wrong and caused all sorts of other breakage. So that change was pretty clearly a change for-the-better, and it just happens to turn out that Chrome seems to have a bug that manifests the same as our old behavior in this particular edge case, it seems.)

Comment 6

[Daniel Holbert [:dholbert]]

(In particular: I think Chrome is mistakenly thinking that the sticky-positioned element and its descendants are entirely outside the scrollport, which is prompting it to not include them in the scrollable area. This is a misjudgement on its part, and it's probably not a behavior that you want your custom-scrollbar-component to strongly depend on...)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

(In particular: I think Chrome is mistakenly thinking that the sticky-positioned element and its descendants are entirely outside the scrollport, which is prompting it to not include them in the scrollable area

Side note: I noticed a related Firefox bug, in the simpler scenario that I'm alluding to here^ where the abspos thing is entirely outside the scrollport. I spun that off as bug 1770516. That's distinct from this report, though, since in the examples here, the abspos thing is inside the scrollport.

I'm going to file a Chromium bug in this case and close this one as INVALID, since I think Firefox is correct here.

(Note: just to be sure there wasn't something else going on here for the original site, I tried out my "extremely fragile" changes from comment 5 [labeled (a)/(b)/(c)] in Chrome on the actual website, https://buntpapier.rash.codes/directives/scrollbar.html , where the sticky thing is <div class="bunt-scrollbar-rail-wrapper-y">; and I confirmed that those same changes inexplicably cause Chrome to change its behavior and match Firefox. I don't think there's any reason that those changes should impact the vertically-scrollable area, so I think this confirms that the Chrome behavior is fragile/buggy and the site is accidentally depending on this Chrome bug.)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (with actual text content that's unreachable in Chrome due to this bug)

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (further reduced from testcase 2, and added buttons to apply tweaks that make Chrome change scrollbar behavior)

Comment 10

[rash]

I know that this behaviour is pretty fragile (not being able to use padding on the scroll container has been a caveat I discovered pretty soon), and I curse my past self for coming up with this "clever" solution, which did work for about five (?) years now in all mayor browsers. This was the only way I could come up with that allows placing something like custom scrollbars without resorting to a wrapper element.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to rash from comment #10)

I know that this behaviour is pretty fragile (not being able to use padding on the scroll container has been a caveat I discovered pretty soon), and I curse my past self for coming up with this "clever" solution, which did work for about five (?) years now in all mayor browsers. This was the only way I could come up with that allows placing something like custom scrollbars without resorting to a wrapper element.

Good to know. Thanks for the bug report in any case! It's good to get interop issues like this addressed (though in this case it'll hopefully be addressed on the Chrome/Safari side).

Hopefully you can adjust your clever solution to avoid depending on this fragile behavior so that it continues to work. :)

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 5 (further reduced)

Here's a testcase where the innermost thing isn't absolute-positioned at all, but just has a margin-left that's large enough to places it off the left side of its sticky-positioned parent (but still inside the scrollport).

Chrome fails to show a scrollbar in this case.

(Reference case coming up, with minor tweak. I'll link to these as the testcase/reference-case for my Chromium bug report.)

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: reference case 5

Here's a reference case for testcase 5, where I've reduced the margin-left by 1px, so as to not-quite-fully push #sticky-inner off the left side of its parent.

(I've also made a complementary 1px reduction to #sticky's left property, so that the overall visual positioning ends up the same. This lets this serve as a legitimate reference case, which should be pixel-for-pixel identical to testcase 5.)

Comment 14

[Daniel Holbert [:dholbert]]

Filed bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=1327794
https://bugs.webkit.org/show_bug.cgi?id=240744

Comment 15

[Daniel Holbert [:dholbert]]

Reopening -- as discussed on the Chromium bug report, their behavior might make sense after all. It sounds like they compute a sticky-positioned box's scrollable-overflow-area as if it were at its static position, which is why they behave as if #sticky-inner were pushed out of the scrollport here.

bug 1748891 is related and I'm hoping to land a fix for that issue soon, which might bring us into interoperability on the testcases here; though we may also need to fix bug 1770516 ([edit] which is now duped to bug 1419142) before we match other browsers on the testcases here.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

S3 since given that Daniel found out it's not a recent regression, it was in fact hit by our old issue.