Scroll end

[hvanops]

Description

Scrollend tells developers when a scroll has completed (including both the scroll itself and any updates to offsets from the scroll) through event listeners. Knowing when a scroll has completed is useful for various reasons, e.g. synchronizing some logic on the snapped section, fetching stuff in a list, triggering new animations, etc.

This feature greatly simplifies the logic for handling end-of-scroll effects, ensuring that they are consistent across many different input modalities. Currently, developers address this need by observing scroll events and building ad-hoc timeout algorithms.

Specification

https://drafts.csswg.org/cssom-view/#scrolling-events

Additional Signals

Standards Positions

• Gecko Positive 1797013 - Implement onscrollend EventHandler
• WebKit Positive https://github.com/WebKit/standards-positions/issues/150

Tests

• WPTs

Browser Bugs

• Chromium

Developer Surveys 2021 scrolling survey report:

• 43% reported it’s somewhat or extremely difficult to work with scrolling
• 55% reported scrollable areas as very or extremely important
• Some developer reactions: “Great, so looking forward to general availability. Using intersection observer here instead is less than ideal: https://nativecarousel.com/” (X.com)

Additional Signals

• Scrollend is used on ~19% of page loads (chromestatus)

[ccpandhare]

We (@rich-hansen, @ccpandhare, @mariusschulz) were working on a very similar proposal, but focused on Safari. Here are some more signals we collected:

1) Impacted interop tests:

• 19 scrollEnd tests in https://github.com/web-platform-tests/wpt/tree/ec979384f0340b8d18c3512f02f42b65bd5f456c/dom/events/scrolling 2) Site breakage and workaround
• A workaround is to use the ‘touchend’ event for iOS devices
• No solid workaround for Safari with non-touch input devices, but the behaviour can be approximated by tracking all scroll events on the browser and using a timeout, with the corresponding runtime perf overhead to do so. 3) Size and current state of the feature
• Size: Not sure
• Current state: Supported by every browser except safari and iOS webview: https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollend_event 4) Browser bug trackers for this
• https://bugs.webkit.org/show_bug.cgi?id=208813

[jgraham]

Sharing some content from #859:

Note: This was also https://github.com/web-platform-tests/interop/issues/528 for Interop 2024, but there were concerns with the use of touch scrolls in some of the scrollend tests. Therefore limiting to programmatic scrolls will make an easier proposal that doesn't depend on mobile testing. With that in mind some proposed tests:

dom/events/scrolling/scrollend-event-fired-for-programmatic-scroll.html dom/events/scrolling/scrollend-event-fired-for-scroll-attr-change.html

[DavMila]

Sharing some content from #859:

Note: This was also #528 for Interop 2024, but there were concerns with the use of touch scrolls in some of the scrollend tests. Therefore limiting to programmatic scrolls will make an easier proposal that doesn't depend on mobile testing. With that in mind some proposed tests:

dom/events/scrolling/scrollend-event-fired-for-programmatic-scroll.html dom/events/scrolling/scrollend-event-fired-for-scroll-attr-change.html

Could we also consider including the following tests:

• scrollend-event-fired-for-mandatory-snap-point-after-load.html
• scrollend-event-fired-for-scrollIntoView.html
• scrollend-event-fired-to-document.html
• scrollend-event-fired-to-window.html
• scrollend-event-handler-content-attributes.html
• scrollend-event-not-fired-after-removing-scroller.tentative.html
• scrollend-event-not-fired-on-no-scroll.html
• scrollend-fires-to-text-input.html

They don't use touch-scrolling so I think that would address the concerns about tests on MacOS.

[dlrobertson]

Thanks @DavMila for digging into this!

• scrollend-event-fired-for-mandatory-snap-point-after-load.html

• scrollend-event-fired-for-scrollIntoView.html

:+1: Great find! I think these make sense. Note that scrollend-event-fired-for-scrollIntoView.html makes use of a for loop to run a bunch of tests in a singular test here. It would be nice to split this out into variants, like we did for scrollend-event-fired-for-programmatic-scroll.html

• scrollend-event-fired-to-document.html

• scrollend-event-fired-to-window.html

I don't entirely understand these tests. I don't understand why the document or window would receive a scrollend event given the current test steps.

• scrollend-event-handler-content-attributes.html

Another good find :+1:

• scrollend-event-not-fired-after-removing-scroller.tentative.html

I think this tests makes sense. Is there a reason it is marked as tentative?

• scrollend-event-not-fired-on-no-scroll.html

Great test.

• scrollend-fires-to-text-input.html

Also seems reasonable.

They don't use touch-scrolling so I think that would address the concerns about tests on MacOS.

Thanks again for digging into this. From a Gecko standpoint, I really only have questions about scrollend-event-fired-to-document.html and scrollend-event-fired-to-window.html.

[dlrobertson]

I'll also note that scrollend-event-fired-to-document.html and scrollend-event-fired-to-window.html make use of scrollElementDown, which makes use of Actions().scroll() here. The scrollend event currently will not be fired for wheel scrolls from webdriver on Gecko. I think that is about to change though.

[DavMila]

• scrollend-event-fired-to-document.html
• scrollend-event-fired-to-window.html

I don't entirely understand these tests. I don't understand why the document or window would receive a scrollend event given the current test steps.

Each promise_test in those tests does 2 scrolls on the inner scroll container targetDiv: one to scroll targetDiv to its max scroll offset, and then another with targetDiv already at its max scroll offset. For the second scroll, the tests expect scrollend to be sent to the document/window since it is the document/window that is scrolled (because the targetDiv is already fully scrolled) even though the pointer is on targetDiv . I did a quick manual test and this seems to work fine on Firefox. Maybe the issue you mentioned about scrollend not being fired for wheel scrolls is the reason the tests aren't passing on Firefox at the moment?

• scrollend-event-not-fired-after-removing-scroller.tentative.html

I think this tests makes sense. Is there a reason it is marked as tentative?

Hm, I'm not sure but I think there might have been a question about whether a scroller that is removed from the DOM mid-scroll should still receive a scrollend event (the second test case). It looks like chrome and firefox behave similarly so we may not have an interop issue there at the moment but maybe we want to decide whether to keep or change that behavior.

[dlrobertson]

I did a quick manual test and this seems to work fine on Firefox. Maybe the issue you mentioned about scrollend not being fired for wheel scrolls is the reason the tests aren't passing on Firefox at the moment?

Ah! Now this makes sense. Yeah, this test should fail currently due to some current limitations of the Firefox webdriver implementation.