Open Bug 1279228 Opened 8 years ago Updated 1 year ago

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

Categories

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

Firefox 47
Desktop
All

Tracking

(firefox101 affected, firefox110 affected)

ASSIGNED
Tracking Status
firefox101 --- affected
firefox110 --- affected

People

(Reporter: sgougeon, Assigned: ksenia)

References

()

Details

(Keywords: webcompat:site-wait, Whiteboard: [sitewait])

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.
Mentor: sledru, cdenizet
Severity: normal → major
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
Flags: needinfo?(sgougeon)
Mentor: cdenizet, sledru
I can reproduce this only if I click once on the horizontal scrollbar first.
Not a regression, reproducible on Firefox 4.0.1.
> reproducible on Firefox 4.0.1.
No typo here? Really 4.0.1 ?
No typo, 4.0.1, double-checked.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → Event Handling
Product: Firefox → Core
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.
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]
Status: NEW → UNCONFIRMED
Ever confirmed: false
Whiteboard: [invalid?]
Note that it doesn't reproduce in Chrome.
(In reply to Paul Silaghi, QA [:pauly] from comment #7)
> Note that it doesn't reproduce in Chrome.

Are they getting the same JS?
Flags: needinfo?(paul.silaghi)
Whiteboard: [invalid?] → [invalid?] btpp-followup-2016-07-05
Not sure how to check that
Flags: needinfo?(paul.silaghi)
On, I hadn't noticed it was gerrit; we could probably just look at their source. I'll take a look.
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.
Component: Event Handling → Desktop
Product: Core → Tech Evangelism
Version: 47 Branch → Firefox 47
Thanks Andrew. I can reproduce this. I have to click the little scroll box for the issue to trigger.
Setting to needsdiagnosis.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [invalid?] btpp-followup-2016-07-05 → [invalid?] btpp-followup-2016-07-05 [needsdiagnosis]
Whiteboard: [invalid?] btpp-followup-2016-07-05 [needsdiagnosis] → [invalid?] [needsdiagnosis]
Priority: -- → P3
(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.
Flags: needinfo?(sgougeon) → needinfo?(dschubert)
Whiteboard: [invalid?] [needsdiagnosis] → [needsdiagnosis]
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.
Flags: needinfo?(dschubert)
See Also: → 129775
Whiteboard: [needsdiagnosis] → [needscontact]
Contacting them via website contact form:
http://www.scilab.org/en/Contact
Whiteboard: [needscontact] → [sitewait]
Received a response that they will look into this issue.
Product: Tech Evangelism → Web Compatibility

See bug 1547409. Moving webcompat whiteboard tags to keywords.

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

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.

Severity: major → --

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.
Assignee: nobody → kberezina
Status: NEW → ASSIGNED
OS: Unspecified → All
Hardware: Unspecified → Desktop

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.

You need to log in before you can comment on or make changes to this bug.