FF scrolls the page following the mouse instead of only when using the wheel or scroll bars
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(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.
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
Updated•8 years ago
|
Comment 2•8 years ago
|
||
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•8 years ago
|
||
> reproducible on Firefox 4.0.1.
No typo here? Really 4.0.1 ?
Comment 4•8 years ago
|
||
No typo, 4.0.1, double-checked.
Updated•8 years ago
|
Updated•8 years ago
|
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•8 years ago
|
||
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•8 years ago
|
||
Note that it doesn't reproduce in Chrome.
Comment 8•8 years ago
|
||
(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 10•8 years ago
|
||
On, I hadn't noticed it was gerrit; we could probably just look at their source. I'll take a look.
Comment 11•8 years ago
|
||
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•8 years ago
|
||
Thanks Andrew. I can reproduce this. I have to click the little scroll box for the issue to trigger. Setting to needsdiagnosis.
Updated•8 years ago
|
Updated•6 years ago
|
Comment 13•6 years ago
|
||
(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•6 years ago
|
||
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•6 years ago
|
||
Contacting them via website contact form: http://www.scilab.org/en/Contact
Comment 16•6 years ago
|
||
Received a response that they will look into this issue.
Updated•5 years ago
|
Comment 17•5 years ago
|
||
See bug 1547409. Moving webcompat whiteboard tags to keywords.
Comment 18•2 years ago
|
||
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•2 years ago
|
||
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•1 year ago
|
||
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:
- Reproducible regardless of the status of ETP.
- Reproducible on the latest build of Firefox Nightly and Release.
- Works as expected using Chrome.
Reporter | ||
Comment 21•1 year ago
|
||
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.
Description
•