1825879 - More scrollend events than expected during click-and-hold on scrollbar track

Status: RESOLVED DUPLICATE of bug 1963375

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

Description

[Botond Ballo [:botond]]

Attachment: Testcase

Steps to reproduce

1. Load the attached testcase
2. Click on an empty area of the scrollbar track and hold the mouse down until the scrollbar thumb stops moving
3. Observe how the reported scrollend count changes

Note: on some platforms/configurations, the default behaviour is "scroll to click" (thumb jumps immediately to the cursor position), in such cases the bug can reproduced using Shift+click instead.

Expected results

Only one scrollend event is fired once the thumb reaches its final destination.

(Note, the final destination varies between platforms, it can be the cursor position or the end of the scrollbar track.)

Actual results

Two scrollend events are fired: one near the beginning of the animation (after the thumb has moved by one page or so), and one at the end.

Comment 1

[Dan Robertson (:dlrobertson)]

Note that this gets worse with general.smoothScroll set to false. With general.smoothScroll=false I'll see more like 50 scrollend events. I don't know how clicking the scroll track scrolls to that location, but based on these results I'm guessing it is composed of several scrollTo or scrollBy calls. Perhaps we need some extra logic for the scrollbar track click case.

Comment 2

[Botond Ballo [:botond]]

(In reply to Dan Robertson (:dlrobertson) from comment #1)

Note that this gets worse with general.smoothScroll set to false. With general.smoothScroll=false I'll see more like 50 scrollend events.

I think that case might be fine, as it's basically doing a bunch of instant scrolls with delays in between them. I think that's conceptually comparable to the case where you're ticking the mouse wheel with instant scrolling and the page scrolls in discrete increments with pauses between them.

Comment 3

[Daniel Holbert [:dholbert]]

Some observations from testing this just now on Linux...

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

2. Click on an empty area of the scrollbar track and hold the mouse down until the scrollbar thumb stops moving

• In Firefox on my Ubuntu 24.04 (Linux) desktop machine, simply clicking the scrollbar track instantly moves the scrollbar-thumb to that location -- I think that's due to the gtk-primary-button-warps-slider setting, which defaults to true in GTK as of at least several years back (though some users disable this behavior). So: on this config, it doesn't matter whether you click or click-and-hold, since the scroll action is instantaneous and complete rather than incremental/paged.

• And in the testcase on this bug here, clicking the scrollbar track only increments the reported "Scrollend count" by 1, which matches "Expected results" (hooray!)

• However: in "testcase 2" from bug 1963375, clicking in the scrollbar-track still increments the scrollend count by 2 in Firefox (darn) vs. 1 in Chrome.

Not sure what the reason is for that 1-vs-2 difference between those two testcases; possibly it's due to the scrollable area being top-level vs. a scrollable div? Or maybe some other subtle difference between the testcases.

Comment 4

[Botond Ballo [:botond]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

• And in the testcase on this bug here, clicking the scrollbar track only increments the reported "Scrollend count" by 1, which matches "Expected results" (hooray!)

• However: in "testcase 2" from bug 1963375, clicking in the scrollbar-track still increments the scrollend count by 2 in Firefox (darn) vs. 1 in Chrome.

Interesting; I'm getting 2 on both testcases (with click-and-hold -- one near the beginning, and one near the end; with just a single click, I get 1 on both testcases).

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast to demonstrate comment 3

Huh, I wonder why we're seeing different results.

I just retested to confirm and I'm still seeing what I described in comment 0. Here's a screencast. I see the same results in Wayland & Xorg, FWIW (doesn't matter which one I use).

For the purposes of the screencast, I used the "screenkey" tool to make it visually clear when & for-how-long I click. (To have that tool work, I had to use Xorg; and for whatever reason my cursor refuses to show up in screencasts recorded on Xorg. shrug, can't have it all. :)) Most of the clicks in this screencast were single-clicks, though some were click-and-hold (but it didn't matter to my results).

Comment 6

[Botond Ballo [:botond]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

Huh, I wonder why we're seeing different results.

Ah, based on the screencast, it's because we have different default configurations and so are testing slightly different scenarios:

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

Note: on some platforms/configurations, the default behaviour is "scroll to click" (thumb jumps immediately to the cursor position), in such cases the bug can reproduced using Shift+click instead.

My default behaviour is "thumb moves smoothly in the direction of the clicked position" (and this is what my observations in comment 4 were based on). Your seems to be "thumb jumps immediately to the clicked position" (a.k.a. "scroll to click").

I suspect if you use Shift+click instead, you will now see the same behaviour as in comment 0 / comment 4.

(Interestingly though, if I use Shift+click, I do get the "immediate jump" behaviour, but I only get 1 scrollend event in both testcases. That's still a bit mysterious.)

Comment 7

[Botond Ballo [:botond]]

This was fixed as part of the work on bug 1963375.