Bug 231953 – Element with position: sticky after sticking, starts to move incorrectly when scrolling

• Component: Scrolling
• Status: RESOLVED FIXED

Created attachment 441720 [details]
Video

Element with position: sticks after sticking, starts to move incorrectly when scrolling.
Check it https://jsfiddle.net/vne3zx7s/4/
iOS 15.0.2

Attached video, watch it
ty

[Radar WebKit Bug Importer]

<rdar://problem/84662329>

[Martin Robinson]

Created attachment 443675 [details]
Testcase

[Martin Robinson]

Hi! Thanks for reporting this issue. It's a bit hard to see what is going wrong in the video. Would you mind explaining in what way the sticky element is moving incorrectly?

Created attachment 445810 [details]
Screenshot

(In reply to Martin Robinson from comment #4)
> Привет! Спасибо, что сообщили об этой проблеме. Сложно увидеть, что не так
> на видео. Не могли бы вы объяснить, как неправильно движется липкий элемент?

Hi! See attached screenshot. Pointed out the problem and pointed timecode.

[Bruno Stasse]

Created attachment 447214 [details]
Testcase2

I am also experiencing this issue on iOS 15.2. Note that I started seeing it since iOS 15. It did not happen before, so this should probably be considered a REGRESSION. As far as I can tell it only affects iOS, not macOS.

It is very problematic as elements with position: sticky do not move correctly with the scroll, they are late compared to other elements, creating jank. This makes for a very poor experience.

I created a new testcase where I think the problem is more visible. See Testcase2 and Video_testcase2.

While scrolling up and down inside the scroll container, you should only see yellow inside (the color of the spacers elements and the sticky element). What actually happens is that you see the scroll container red background because the element with position: sticky is not correctly painted at the position it should be, revealing the background.

[Bruno Stasse]

Created attachment 447215 [details]
Video_testcase2

[Bruno Stasse]

Observation: sorry for the multiple comments, I just noticed that the problem only seems to be happening after the element has sticked (been fixed to the viewport) once, it does not happen before that.

[Bruno Stasse]

Additional observations:

- The problem does not occur with page/body scroll, only inside element scroll containers.

- The sticky element is only late to be positioned when scrolling in the direction of the side it has been last stuck on. In Testcase2, as the element has `top: 0`, it is only late to be positioned when scrolling to the top, and therefore only shows the scroll container red background above it. If you add the rule `bottom: 0`, you will see that it has the opposite behaviour. After sticking to the bottom, the scroll container red background will appear below it.

This bug makes `position: sticky` pretty unusable on iOS inside element scroll containers. It would be great if it could be fixed quickly so it doesn't affect another iOS version. In the meantime, if anyone find a workaround for iOS 15 to 15.2, please share!

[Simon Fraser (smfr)]

For some reasons the UI-side positioning of the sticky layer isn't matching the scrollview motion.

[Simon Fraser (smfr)]

I can reproduce on macOS too.

[Simon Fraser (smfr)]

Things seem to only go bad after you hit the start or and and rubberband.

[Simon Fraser (smfr)]

I believe the issue here is that in a given scrolling tree commit, we update the scrolling node for the overflow scroll with a new scroll position, but fail to update the sticky viewport constraints on the sticky node, so that "last committed scroll position" on the scrolling node, and "constraining-rect-at-last-layout" on the sticky node get out of sync.

[Simon Fraser (smfr)]

And that happens because ScrollingNodeChangeFlags::LayerGeometry is not set for the sticky node.

[Simon Fraser (smfr)]

Created attachment 453796 [details]
Patch

[EWS]

Committed r290812 (248048@main): <https://commits.webkit.org/248048@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 453796 [details].

[Simon Fraser (smfr)]

*** Bug 235576 has been marked as a duplicate of this bug. ***

[Sam Sneddon [:gsnedders]]

Just to let everyone know, for those who care about Safari, the fix for this has shipped in Safari 15.5.