Sticky element is bigger than viewport

[ruijdacd]

I'm having an issue, when the sticky element is bigger than the viewport and scrolling back up, instead of going back to top: 0px; it goes into a negative value like top: -77px;. The latter varies a lot depending on the height of both the sticky and the viewport or the scroll speed.

I'll attach a working example here

[ruijdacd]

https://cl.ly/a5707336755c

[danielberndt]

Thanks for the recording. This definitely helps. To narrow the issue down: does the problem occur only when resizing the screen? Or is it caused by expanding/collapsing the accordion? Does it also happen if you remove the animation from the accordion?

[ruijdacd]

Thanks for the quick reply. The problem happens when the sticky element is bigger than the viewport. Even if I refresh the page and don’t click on the accordions or resize the window the problem still happens.

[ruijdacd]

I’ll try to get another recording of it, maybe tomorrow, since I don’t have the computer with me.

[ruijdacd]

Sorry for the late reply. Here's the recording I mentioned: https://cl.ly/a8ce3e272729

From what I can tell, it happens when the sticky element is bigger than the viewport and depending on the scroll speed it gets different values. Most of the time it goes upwards or downwards and rarely it goes back to its intended place (top: 0px)

[danielberndt]

I just tried to reproduce it by creating a similar case where both the sticky box and its container are slightly larger than the viewport and scrolled around like crazy. Both, Chrome and Firefox failed to show the same kind of behaviour you're describing. So I assume there's some additional complexity that isn't apparent just from looking at the videos. Do you use any overflow: xxx or transform: xxx in any of the surrounding containers? This sometimes led to browser bugs.

What does the element inspector say about the sticky box once it's in an 'off' state? ideally it should be position: sticky; top: [value of this.props.offsetTop]

[ruijdacd]

Oh, that's weird. I can reproduce it every time.

I've checked and I'm not using any overflows or transforms on its containers. Just basic layout styling with flexbox (display: flex, flex-direction: column, order: -1, etc...)

When it's in an off state, the values are not consistent. Sometimes it goes to its correct value, either by becoming sticky or relative (position: sticky; top: 126px; or position: relative; top: 0px)

Last week I tried to create a similar setup on CodeSandbox, but I didn't manage to do it with the free time I had. I'll try to create another one this week.

[danielberndt]

I just released v0.7.1 with several fixes. I also discovered a configuration which showed similar issues to yours. It showed up when the scroll pane was not an offsetParent (i.e. the scrollpane had no position:relative or absolute).

Please check out the latest version an let me know if it works!

[ruijdacd]

Wow, you fixed it. I feel like it's even smoother now.

Thanks for the help 👍

[danielberndt]

Yes, while working on the new docs, I realized that collapsing and expanding the contents didn't always behave quite right. So I spent some time fixing this as well :)