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

Status: RESOLVED 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] (PDT, UTC-7)]

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] (PDT, UTC-7)]

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