1279228 - FF scrolls the page following the mouse instead of only when using the wheel or scroll bars

Status: RESOLVED INCOMPLETE

(Web Compatibility :: Site Reports, defect, P3)

Description

[sgougeon]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

For instance on the page
https://codereview.scilab.org/#/c/18222/7/scilab/CHANGES
just move the mouse on the right green side of the diff, horizontally, without any click.


Actual results:

The page is scrolled according to the mouse position, without using scroll bars.
This is very uncomfortable, because the heads of lines get hidden when it is not required.
This behavior occurs for all diff pages on this CodeReview.
Requires to switch to Chrome to use this CodeReview.



Expected results:

Pages should be scrolled only when the mouse wheel is used, or when dragging the scroll bars.

Comment 1

[Loic]

I can't reproduce the issue, it scrolls only when I use the mouse wheel, not when I'm moving the mouse over the green area.

Could you test with a fresh profile, please.
https://support.mozilla.org/fr/kb/utiliser-gestionnaire-profils-creer-supprimer-profils

Comment 2

[Paul Silaghi, QA [:pauly]]

I can reproduce this only if I click once on the horizontal scrollbar first.
Not a regression, reproducible on Firefox 4.0.1.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

> reproducible on Firefox 4.0.1.
No typo here? Really 4.0.1 ?

Comment 4

[Paul Silaghi, QA [:pauly]]

No typo, 4.0.1, double-checked.

Comment 5

[sgougeon]

Thanks all for your great reactivity!
I confirm 
a) with a fresh profile, i need to click first on the horizontal bar to trigger the behavior
b) i noted this behavior a long time ago (may be 2 or 3 years)
Thanks again.

Comment 6

[Mats Palmgren (inactive)]

Well, that page is assigning element.scrollLeft from JS so this seems to be a bug
in the scripts on the site, not in Firefox.  Here's the JS stack for the call, fwiw:

(rr) call DumpJSStack()
0 La(a = [object Object]) ["https://codereview.scilab.org/gerrit_ui/E00240A8DB245851006DE237B67C4ECF.cache.js":91]
    this = [object Window]
1 fa/<(776, 0) ["https://codereview.scilab.org/gerrit_ui/E00240A8DB245851006DE237B67C4ECF.cache.js":94]
    this = [object Object]
2 qod(c = [object Object], a = 776, b = 0) ["https://codereview.scilab.org/#/c/18222/7/scilab/CHANGES":224]
    this = [object Window]
3 bkb() ["https://codereview.scilab.org/#/c/18222/7/scilab/CHANGES":785]
    this = Class$S508@ae
4 god/c<([object Object]) ["https://codereview.scilab.org/#/c/18222/7/scilab/CHANGES":458]
    this = [object Window]
5 U2b(a = [unavailable], b = [unavailable], c = [unavailable]) ["https://codereview.scilab.org/#/c/18222/7/scilab/CHANGES":448]
6 X2b(b = [function], c = [object Window], d = [object Arguments]) ["https://codereview.scilab.org/#/c/18222/7/scilab/CHANGES":63]
    this = [object Window]
7 W2b/<([unavailable]) ["https://codereview.scilab.org/#/c/18222/7/scilab/CHANGES":58]
8 h.signal(a = [object Object], b = "scroll", [object Object]) ["https://codereview.scilab.org/gerrit_ui/E00240A8DB245851006DE237B67C4ECF.cache.js":274]
    this = [object Window]
9 kf/<([object UIEvent]) ["https://codereview.scilab.org/gerrit_ui/E00240A8DB245851006DE237B67C4ECF.cache.js":106]
    this = [object HTMLDivElement]

Comment 7

[Paul Silaghi, QA [:pauly]]

Note that it doesn't reproduce in Chrome.

Comment 8

[Andrew Overholt [:overholt]]

(In reply to Paul Silaghi, QA [:pauly] from comment #7)
> Note that it doesn't reproduce in Chrome.

Are they getting the same JS?

Comment 9

[Paul Silaghi, QA [:pauly]]

Not sure how to check that

Comment 10

[Andrew Overholt [:overholt]]

On, I hadn't noticed it was gerrit; we could probably just look at their source. I'll take a look.

Comment 11

[Andrew Overholt [:overholt]]

I looked and couldn't figure it out in a few minutes so I filed a Gerrit issue: https://bugs.chromium.org/p/gerrit/issues/detail?id=4421. Moving to TE for now.

Comment 12

[Adam Stevenson [:adamopenweb]]

Thanks Andrew. I can reproduce this. I have to click the little scroll box for the issue to trigger.
Setting to needsdiagnosis.

Comment 13

[Mike Taylor [:miketaylr]]

(In reply to Loic from comment #1)
> I can't reproduce the issue, it scrolls only when I use the mouse wheel, not
> when I'm moving the mouse over the green area.
> 
> Could you test with a fresh profile, please.
> https://support.mozilla.org/fr/kb/utiliser-gestionnaire-profils-creer-
> supprimer-profils

Turns out you have to scroll the horiz scrollbar at the bottom to enable the weird mouse-follow scroll behavior. Still an issue.

Dennis, can you take a look please? Also reproducible for the (tiny) vertical. See the relevant stack in comment #6.

Comment 14

[Dennis Schubert [:denschub]]

Sure!

There is a mousedown event handler on that scrollbar, which adds a mousemove handler to the document that looks like this:

> function p(m) {
>   1 != m.which ? h.off(document, "mousemove", p) : w.moveTo(u + w.total / w.size * (m[t] - s))
> }

Basically, they set the scroll position to whatever the current mouse position is, unless `MouseMoveEvent.which` is not 1, in which case they'd remove the mousemove listener, and thus stop scrolling. In Chrome, `MouseMoveEvent.which` is 1 if the left mouse button is clicked, and 0 otherwise, so the mousemove listener would remove itself as soon as the user releases the mouse button.

In Firefox, `MouseMoveEvent.which` is always 1, even if no button is pressed. This is nothing new, though, as we broke this behavior somewhere between Firefox 1.0 and Firefox 1.5, see bug 129775. I doubt we'll see a patch on that soon. :)

Gerrit should probably avoid using `MouseMoveEvent.which`, because it is broken and non-standard, and use `MouseMoveEvent.buttons` instead, which works correctly in Firefox. In fact, they already have (they somewhere in the event chain set .which based on .buttons), as it works correctly in newer versions of Gerrit: https://git.eclipse.org/r/#/c/127293/2/org.eclipse.scout.rt.shared/src/main/java/org/eclipse/scout/rt/shared/http/ApacheMultiSessionCookieStore.java

It's probably worth to try to reach out to scilab.org and make them aware of that, maybe they can update their Gerrit instance.

Comment 15

[Adam Stevenson [:adamopenweb]]

Contacting them via website contact form:
http://www.scilab.org/en/Contact

Comment 16

[Adam Stevenson [:adamopenweb]]

Received a response that they will look into this issue.

Comment 17

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 18

[Oana Arbuzov [:oanaarbuzov]]

The issue is still reproducible after clicking the scroll bar on the green side of the diff.

Tested with:
Browser / Version: Firefox Nightly 101.0a1 (2022-04-14)
Operating System: Windows 10 Pro

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 20

[Raul Bucata]

The issue is still reproducible. Clicking on the horizontal scroll bar in the far right of the screen triggers scrolling depending on the mouse movement on the page.

Tested with:

Browser / Version: Firefox Nightly 110.0a1 (2023-01-11) (64-bit) Chrome Version 109.0.5414.75 (Official Build) (64-bit)) /
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome.

Comment 21

[sgougeon]

Please be aware that the website https://codereview.scilab.org where the issue has been detected and can still be tested up to now will be turned off and removed by a month.

Comment 22

[Dennis Schubert [:denschub]]

Closing as incomplete as per the previous comment.