Bug 227246 – REGRESSION (r271439): JS-Smooth scrolling with snap points broken on Apple Music pages

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Scrolling

[Simon Fraser (smfr)]

JS-driven smooth scrolling is broken when used in combination with scroll snapping, which breaks Apple Music pages.

Testcase: https://codepen.io/danrichman/pen/ZEeNKvb

[Simon Fraser (smfr)]

It seems that after r271439 snapping happens after each call to scrollBy(), thereby breaking pages that want to smoothly scroll (via JS) to the next snap point.

[Simon Fraser (smfr)]

<rdar://79591028>

[Simon Fraser (smfr)]

Maybe we should revert r271439 until we have smooth scrolling enabled by default?

[Simon Fraser (smfr)]

The testcase works in Chrome and Firefox, so do they not snap for programmatic scrolls?

[Martin Robinson]

(In reply to Simon Fraser (smfr) from comment #4)
> The testcase works in Chrome and Firefox, so do they not snap for
> programmatic scrolls?

Chrome and Firefox definitely do snapping for programmatic scroll events.

I'm not sure about the Apple Music page, but in the test case the `scroll-snap-type: y mandatory;` rule is applied to the body tag. Normally the body tag doesn't accept `scroll-snap-type` rules, but WebKit maintains it for backwards compatibility with an old version of the specification. This means that scroll snapping is not enabled for Chrome and Firefox, but is for WebKit browsers. If you move the rule to the html tag, then the animation is broken in different ways in Chrome and Firefox.

Removing this backward compatibility feature is tracked by: https://bugs.webkit.org/show_bug.cgi?id=200643.

[Simon Fraser (smfr)]

The previous demo used scroll-snap-type on body, which has different behavior in WebKit.

Here's a testcase with scroll-snap-type on the root:
https://codepen.io/smfr/pen/JjWqVoz

This shows the same behavior in Chrome and Safari now (Firefox seems a bit broken).

[Simon Fraser (smfr)]

This is correct behavior.