Bug 227300 – Mandatory scroll snapping doesn't work correctly in tables with position:sticky

• Status: RESOLVED
• Resolution: FIXED
• Component: Scrolling

[Simon Fraser (smfr)]

In this testcase https://codepen.io/snewcomer/pen/wvJLyzj the snapping in X doesn't behave like mandatory, when it should.

[Martin Robinson]

This seems broken in STP, but works for me in trunk. Perhaps this was fixed by a recent change?

[Simon Fraser (smfr)]

I can reproduce at r279166.

[Martin Robinson]

Ah, after a bit more debugging, I think the key thing here is asynchronous overflow scrolling. When I have it turned off, snapping works as expected. I suspect that the code is not snapping where it should be at some point.

[Martin Robinson]

Similarly to https://bugs.chromium.org/p/chromium/issues/detail?id=835301 what seems to be happening here is that the `position: sticky` table headers are always at the current scroll offset. This means that these cells are always chosen as the destination of the snap operation, which means that we always snap to the current snap offset!

I think that the solution here is to ensure that when we calculate snap points, we should not take into account sticky positioning of children.

[Martin Robinson]

It seems what might be happening in this case is that a layout is happening in between the scroll operation and the snap operation, which seems a bit wrong.

[Martin Robinson]

(In reply to Martin Robinson from comment #5)
> It seems what might be happening in this case is that a layout is happening
> in between the scroll operation and the snap operation, which seems a bit
> wrong.

Ah, no this is correct. The scroll position / layout will happen while fingers are down on the touchpad, but the snap won't happen until fingers come up (ie after sticky repositioning).

[Radar WebKit Bug Importer]

<rdar://problem/79971196>

[Martin Robinson]

This seems to be the relevant specification in this case:
https://drafts.csswg.org/css-position-3/#stickypos-scroll

> For the purposes of any operation targeting the scroll position
> of a sticky positioned element (or one of its descendants), the sticky 
> positioned element must be considered to be positioned at its initial
> (non-offsetted) position

My reading of this is that regardless of the whether asynchronous overflow scrolling is on, we should use the original (non-offsetted) position of the sticky-positioned element for the snap point.

[Martin Robinson]

Created attachment 439031 [details]
Patch

[Martin Robinson]

Created attachment 439038 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 439038 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=439038&action=review

You'll need to skip the test on iOS.

> Source/WebCore/page/scrolling/ScrollSnapOffsetsInfo.cpp:334
> +        OptionSet<MapCoordinatesMode> options;
> +        options.add(UseTransforms);
> +        options.add(IgnoreStickyOffsets);

OptionSet<MapCoordinatesMode> options = { UseTransforms, IgnoreStickyOffsets };

[Martin Robinson]

Created attachment 439146 [details]
Patch

[EWS]

Committed r283100 (242158@main): <https://commits.webkit.org/242158@main>

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