Created attachment 441720 [details]
Element with position: sticks after sticking, starts to move incorrectly when scrolling.
Check it https://jsfiddle.net/vne3zx7s/4/
Attached video, watch it
Created attachment 443675 [details]
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]
(In reply to Martin Robinson from comment #4)
> Привет! Спасибо, что сообщили об этой проблеме. Сложно увидеть, что не так
> на видео. Не могли бы вы объяснить, как неправильно движется липкий элемент?
Hi! See attached screenshot. Pointed out the problem and pointed timecode.
Created attachment 447214 [details]
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.
Created attachment 447215 [details]
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.
- 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!
For some reasons the UI-side positioning of the sticky layer isn't matching the scrollview motion.
I can reproduce on macOS too.
Things seem to only go bad after you hit the start or and and rubberband.
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.
And that happens because ScrollingNodeChangeFlags::LayerGeometry is not set for the sticky node.
Created attachment 453796 [details]
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].
*** Bug 235576 has been marked as a duplicate of this bug. ***
Just to let everyone know, for those who care about Safari, the fix for this has shipped in Safari 15.5.