2015089 - scrollend event does not fire for each scroll

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P2)

Description

[Nige White]

Attachment: scrollend-bug.html

If we set scrollTop twice, both scroll and scrollend should fire twice.

Or, if "optimized", the scrollend could fire once AFTER both scrolls have been completed (See example running on Safari).

In any case, a scrollend should always fire AFTER all scrolls within the same animation frame have been completed.

Run the attached file.

It performs two scrolls.

On scroll it adds a class to the scrolling element.

On scrollend, it removes that class.

On all other browsers this works, and the element ends up with the "scrolling" class removed.

On Firefox, the scrolling class is stuck. I believe this is a common pattern, to flag an element as scrolling using a CSS class.

Chrome seems to have the most logical behaviour.

This pattern works with the legacy delayed synthesized scrollend event. This issue is preventing us (probably others) from moving on to using the native scrollend event.

Comment 1

[Nige White]

On second thoughts, I think Safari makes more sense. Multiple scroll commands are processed by the element, but finally, only one scrollend event comes out of the end of that process.

Comment 2

[Ina Popescu, Desktop QA]

I was able to reproduce this issue in Firefox 147.0.3 on macOS 15 using the test case provided. Marking this as New.

Comment 3

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Botond Ballo [:botond]]

I agree the observed behaviour here is wrong. I don't have a diagnosis offhand but will circle back to this and investigate further.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Though I just skimmed the test case so I haven't yet grasped what the test case in comment 0 does exactly, I would say our behavior matches what the spec describes.

From the spec, specifically the
"Whenever an element gets scrolled (whether in response to user interaction or by an API), the user agent must run these steps:" section:

3. If (target, "scrollend") is already in doc’s pending scroll events, abort these steps.
4. Append (target, "scrollend") to doc’s pending scroll events.

So if there's already an scrollend event in the queue, no new scrollend event is queued.

Now I re-read the test case carefully, what the test does roughly is;

1. In a setTimeout callback
2. Do scrollTop = 100
3. A scroll event and a scrollend event are appended into the pending queue
4. A scroll event is dispatched
5. Thus a (capture=true) scroll event listener's Promise is resolved
6. At this moment, the other callback functions of scroll/scrollend listeners haven't yet been called
   6-1) Thus, both of scrollCount and scrollEndCount are 0
7. Do scrollTop = 200 in the micro task of the Promise
8. At this moment, a new scroll event MIGHT be appended in the queue, since the previous scroll event has been already processed, NOTE that the spec is ambiguous though
   8-1) But a new scrollend event is never appended since there's the previous scrollend event in the queue

I may be overlooking something though.

Comment 6

[Botond Ballo [:botond]]

Thanks for the analysis, Hiro!

I think the outcome that the order of dispatched events is "scroll, scrollend, scroll" is clearly inconsistent with the design intent behind scrollend events and impacts their practical usefulness.

If the current spec requires (or even permits) this outcome, I think we need to file a spec issue to address that.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

A workaround I can think of is to wait a requestAnimationFrame callback just before the second scrollTop.

--- scrollend-bug.html.old	2026-03-12 09:44:55.149316533 +0900
+++ scrollend-bug.html	2026-03-12 09:43:19.118660035 +0900
@@ -64,6 +64,8 @@ setTimeout(async () => {
     console.log('Scroll count:', scrollCount);
     console.log('Scroll end count:', scrollEndCount);
 
+    await new Promise(resolve => requestAnimationFrame(resolve));
+
     container.scrollTop = 200;
     await scrollPromise(container);

I've confirmed with this change, there are two scrollend events can be observed.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

A tricky part to change our implementation is here

void ScrollContainerFrame::PostScrollEndEvent() {
  if (mScrollEndEvent) {
    return;
  }

  // The ScrollEndEvent constructor registers itself.
  mScrollEndEvent = new ScrollEndEvent(this);
}

We check in each scroll container whether there's already a scrollend even in the pending queue. An advantage that each scroll container has it is

a) checking there's already one is quite fast
b) if the scroll container gets destroyed while the event in the queue, the event is easily discarded

So we will have to check it in PresShell::PostScrollEvent, even it would be slow.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Hmm now I wondered on Chrome the scroll position when the first scrollend event is received, it's 200. Is that what web developers want to see? That's super confusing.

Comment 10

[Botond Ballo [:botond]]

Nige, how useful is the workaround discussed in comment 7 for the purposes of adopting the native scrollend event in your codebase?

Comment 11

[Botond Ballo [:botond]]

Attachment: Bug 2015089 - Revoke pending scrollend event on new scroll operation. r=hiro

Comment 12

[Botond Ballo [:botond]]

I came up with a patch that fixes the WPT added in bug 2025588 (and the behaviour on the original page in comment 0) and doesn't regress any other tests. I think we'll still want to file the spec issue discussed in comment 6, but hopefully we can proceed with the fix in parallel.

Comment 13

[Botond Ballo [:botond]]

Filed a spec issue at https://github.com/w3c/csswg-drafts/issues/13772.

Comment 14

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #13)

Filed a spec issue at https://github.com/w3c/csswg-drafts/issues/13772.

The spec issue has been resolved so implementation work in this bug has been unblocked.

(The resolution is different from what the draft patch currently implements, so the patch will need to be revised.)

Comment 15

[Nige White]

Is anybody making any progress on this?

Because I suspect that universally, applications which need to clear a state or take some other action when a scroll is finished use a timer which kicks off on every scroll event, cancelling the last timer from the last scroll event if any.

This is incredibly wasteful.

But the scrollend event MUST actually work, and fire when a scroll has completely finished for this pattern to stop being used. Otherwise some states will be locked in place.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

Sorry for the inconvenience. We have planned to fix this bug in this H2, but unfortunately we haven't yet started on this now.

I might be able pick this bug on this week. Thanks!

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 2015089 - Post the visual viewport's scroll and scrollend events exactly once. r?botond

VisualViewportScrollEvent's constructor posted itself to the pres shell, and so
did the constructor of its base class VisualViewportScrollEndEvent, so every
visual viewport scroll event landed in the pending scroll events twice. The
duplicate is harmless today only because firing the first copy revokes the
event. Post from PostScrollEvent()/PostScrollEndEvent() instead, once per
event.

Comment 18

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 2015089 - Empty the pending scroll events before dispatching them. r?botond

Per the CSSWG resolution on w3c/csswg-drafts#13772, the pending scroll events
are snapshotted and the list emptied before any of them is dispatched, so a
scroll performed by a scroll event listener queues its own events for the next
tick. PresShell::RunScrollSteps already moved the list aside, but a scroll
container and a visual viewport each keep a reference to the event they posted
as their "one is already queued" marker, and that reference outlived the queue
entry: an instant scroll from a scroll event listener was folded into the
scrollend already being dispatched, and the second scroll never got a scrollend.

Detach() drops those references for the whole batch up front. A detached event
outlives the object that posted it, so the events hold a WeakFrame / WeakPtr
rather than a raw pointer plus Revoke() on destruction.

The scroll container case is covered by the WPT added in bug 2025588, which
this makes pass. For the visual viewport, a scroll of an element that is inside
the layout viewport but outside the visual viewport scrolls visually only,
which queues a visual viewport scroll event without the layout viewport moving.
The WPT for it needs a pinch zoom gesture, which GeckoDriver does not support
yet (bug 2006404), so it is marked as expected FAIL; it passes on Chrome
Canary. The mochitest covers the same behaviour in Firefox by zooming with
setResolutionAndScaleTo.

Comment 19

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2015089 - Remove dead scroll event tracking code. r=#layout,hiro

We disabled this a while ago, so it can go.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3f2e441d843b
https://hg.mozilla.org/integration/autoland/rev/d32a6bfe0aa2
Post the visual viewport's scroll and scrollend events exactly once. r=emilio

Comment 21

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2015089 - Simplify scroll event handling. r=#layout,hiro

This makes the scroll event handling more per-spec, and I think it's a
much simpler approach than bug 2015089.

Note that this subtly changes behavior around the edges, which I'm not
totally happy about: With this patch, if you reframe, you might end up
with two scroll events in the same frame, while pre-patch you end up
just with one. However, pre-patch has a separate set of issues, e.g. you
might end up with zero scroll events rather than one if you scroll and
then go display: none or reframe.

With this setup it is very easy to fix tho, by keeping mWeakFrame in
ScrollEvent and refusing to fire if the frame is dead. So if this causes
trouble it is trivial to go back to the previous behavior. But I think
it's better to incorrectly fire one more event than incorrectly not
firing any event...

Comment 22

[Emilio Cobos Álvarez [:emilio]]

Comment 21's try, ftr: https://treeherder.mozilla.org/jobs?repo=try&revision=64a784c0e6fb92d37c8d46eb34840bd378eacff2

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a3a4ed561d0b
https://hg.mozilla.org/integration/autoland/rev/8ebb5140e894
Remove dead scroll event tracking code. r=layout-reviewers,dshin

Comment 24

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/d32a6bfe0aa2

Comment 25

[amarc]

https://hg.mozilla.org/mozilla-central/rev/8ebb5140e894

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5b5dced46d8f
https://hg.mozilla.org/integration/autoland/rev/9db9e1767922
Simplify scroll event handling. r=hiro,layout-reviewers

Comment 27

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2015089 - Follow-up null-check + consistency nits. r=hiro!

Make the code more similar between scroll / scrollend and add a missing
nullcheck.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4ce0e4ecddb2
https://hg.mozilla.org/integration/autoland/rev/88a4b2dab83d
Follow-up null-check + consistency nits. r=hiro,layout-reviewers

Comment 29

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/9db9e1767922
https://hg.mozilla.org/mozilla-central/rev/88a4b2dab83d

Comment 30

[Nige White]

This is not fixed in Firefox 159.0a1 (2026-09-28) (aarch64).

A scrollend must follow ANY scroll event even if a visible scroll is not actually done. If there was a scroll event emitted there must be a scrollend event after that. Otherwise application state can get stuck.

Run the example file attached to this ticket. The scrolling class is stuck on the scrollable element.

A scroll is requested, but then the overflowing element is cut back to height : 50em which no longer overflows.

It logs

Scroll count: 2
Scroll end count: 1

And the `scrolling class remains on the container element.

Comment 31

[Nige White]

(In reply to Nige White from comment #30)

This is not fixed in Firefox 159.0a1 (2026-09-28) (aarch64).

A scrollend must follow ANY scroll event even if a visible scroll is not actually done. If there was a scroll event emitted there must be a scrollend event after that. Otherwise application state can get stuck.

Run the example file attached to this ticket. The scrolling class is stuck on the scrollable element.

A scroll is requested, but then the overflowing element is cut back to height : 50em which no longer overflows.

It logs

Scroll count: 2
Scroll end count: 1

And the scrolling class remains on the container element.

Comment 32

[Emilio Cobos Álvarez [:emilio]]

The example shows:

Scroll count: 0
Scroll end count: 0
Scroll count: 2
Scroll end count: 2
container
Final Scroll count: 2
Final Scroll end count: 2

for me, what am I missing? In any case I think we should not reopen this, filing a separate ticket is less messy to track whatever is remaining.

Comment 33

[Emilio Cobos Álvarez [:emilio]]

Let's keep the discussion in bug 2076420. I can reproduce the Scroll end count: 1 in 157, but not in 159, FWIW.