1612561 - 100% height sticky child prevents container height reduction when scrolled to bottom

Status: VERIFIED FIXED

(Core :: Layout: Positioned, defect, P3)

Description

[alexander]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

I have a sticky overlay on a scrolling container:

<div class="scroll">
<div class="sticky">I'm sticky</div>
... more items here
</div>

This sticky overlay has height 100% and negative margin on bottom same as container height (I tried different techniques here) — this means it is INSIDE CONTAINER but it acts somewhat as position fixed as it is always at the same place when you scroll and it covers whole container.

Take a look at this demo:
https://stackblitz.com/edit/firefox-position-sticky-bug?file=src%2Fapp%2Fapp.component.html

Click add a few times so scroll appears, scroll to bottom and click remove.

Actual results:

When you scroll container to the bottom and start removing items from it, meaning reducing its height, sticky element prevents it.

Expected results:

Sticky element should not keep container from size reduction. When elements at bottom are removed container should scroll up a little so it is scrolled to bottom of the new layout. Chrome works this way, you can try the same demo in Chrome.

Comment 1

[alexander]

Workaround is to have sticky height of calc(100% - 1px) so that it never touches bottom of container.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Seems to work in Nightly, mind confirming? I think this was fixed by bug 1598112.

Note, though, that the spec is quite unclear here :/

Comment 3

[Alice0775 White]

Attachment: reporter's html without any external JS liblaries

I can still reproduce the issue on Nightly74.0a1(20200131013147) Windows10.
And I can also reproduce this issue on Firefox27 with layout.css.sticky.enabled=true;
So, this seems to be not regression.

Comment 4

[Jani]

Still an issue in 87.0b9.

The workaround calc(100% - 1px) works fine as a workaround for the issue. Interestingly, I cannot see that 1px gap in Firefox whereas in Chrome it is clearly visible and needs to be filled with eg. box-shadow.

Comment 5

[Gregory Pappas [:gregp]]

This still reproduces in recent versions.

Comment 6

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: reporter's html without any external JS liblaries

Fixed the "Remove" button for the testcase in comment 3.

Comment 7

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: Bug 1612561 - Add a WPT for removing a sibling of sticky positioned element. r?#layout

Bug 1748891 fixed this bug. Add a WPT testing scenario of the reporter's
testcase.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/303f0de5e7a8
Add a WPT for removing a sibling of sticky positioned element. r=layout-reviewers,emilio

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45932 for changes under testing/web-platform/tests

Comment 10

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/303f0de5e7a8

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 12

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Reproduced the issue on Firefox 87.0b9 on macOS 14.5 by following the infos provided in Comment 0.

The issue is fixed on Firefox 127.0b2. Tests were performed on macOS 14.5, Windows 11 and Ubuntu 24.04.