1667758 - Scroll seems to decrease the speed with no reason

Status: UNCONFIRMED

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

Description

[Marian]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

I updated the Nightly 83.0a1 and when i scroll seams no not working good.

Normal i use Normal version is 81.0

Actual results:

When i scroll by Mouse Wheel the browser animation is like is deceasing the speed of scrolling and starting again fast (normal)

https://www.youtube.com/watch?v=bAPvlIrueZQ look at second 3 and 5
You can put the speed 0.25, still visible to see the speed difference.

Comment 1

[Marian]

I tested the 82.0a1 with MozRegresion and works fine.
Happening with DirectX 11 and Webrender.

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

The scroll animation speed with mousewheel is somewhat dependent on how fast you're rolling the mousewheel. If you roll it slower the animation will be slower and if you roll it faster the animation will be faster as well. The animation speed in 83 did change slightly but if anything it should reduce the difference between the "fast" and "slow" animation speeds, so it should be less noticeable, not more.

Note that on new profiles the animation speed settings are going to be a little different, so using mozregression in the default configuration (which creates a new profile on each run of Firefox) will not be useful if you're trying to bisect this issue. Instead, you should probably use the --profile-persistence=clone-first option with a profile that was created by a 2020-08-25 or earlier build. Please let me know if you're able to do that or not.

Comment 4

[Marian]

1. I know that with the speed. The problem is that the Mouse Wheel has constant speed and the Firefox is like pressing the (brake pedal) with no reason.

2. I selected the Clone-First and selected the Default profile from my 81.0.

   • Now seems the Nightly 83 working good as normal.

What was changed to the Default Profile creation of the 83?

Comment 5

[Kartikaya Gupta (email:[e-mail])]

It's not clear to me from your comments what scenarios you've tested. I assumed from comment 0 that you used your regular 81.0 profile in nightly 83, was that not the case? Or did you create a new profile for nightly 83, and that's where you saw the problem?

The change I'm thinking of was in https://hg.mozilla.org/mozilla-central/rev/cd543a0b85c4#l2.12 where we changed the default values for general.smoothScroll.mouseWheel.durationMaxMS from 400 to 200 and general.smoothScroll.mouseWheel.durationMinMS from 200 to 50 for new profiles.

If you're seeing the problem only in new profiles for 82 and 83 then it's possible that the shorter animation duration is somehow causing animations to clobber each other and resulting in what you're seeing.

Comment 6

[Marian]

Seams the general.smoothScroll.mouseWheel.durationMinMS to 50 cause a weird behavior of the scroll.
I put it back to 200 works good as before (The speed is constant).

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Sorry for the delay in getting back to you. Are you comfortable with setting environment variables and capturing console output from firefox? If so, it would be useful if you set the environment variable MOZ_LOG="sync,timestamp,apz.inputqueue:5,apz.controller:4" and collected the output from firefox when the problem reproduces. If possible, try to avoid doing a lot of stuff in the browser session where you're collecting the output - just start firefox, load the page, do wheel scrolling until the problem occurs, and then shut down firefox. There tends to be a lot of output, so redirecting it to a file is best. Then you can attach the file to this bug.

If you need more detailed steps or if you're not getting any output let me know and I can try and make a custom build that has the output enabled by default or something. Thanks!

Comment 8

[Marian]

I think i need help to do that. Where we can speak?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Usually for synchronous communication, the #apz:mozilla.org Matrix channel is the best place to find me.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Here's some more detailed instructions that might be helpful and/or if you can't find me on Matrix:

• Install Firefox Nightly (if you don't have it already) and make a note of the folder it's installed in (usually it's in C:\Program Files\Firefox Nightly)
• Start Firefox Nightly, go to about:preferences, and check the box for "Restore previous session" if it's not already checked
• Load a long page on which you can reproduce the problem (the previous step and this one just make it so that when you re-start Firefox Nightly later, it will load the page on startup and all you have do is scroll)
• Close Firefox Nightly (and any other running instances of Firefox, just to be safe)
• Go to Windows -> Run and run the cmd.exe command
• This should show you a prompt like C:\Users\foo> where foo is your username
• Type (or copy/paste) the following command: set MOZ_LOG=sync,timestamp,apz.inputqueue:5,apz.controller:4 and hit enter
• Type (or copy/paste) the following command: set MOZ_LOG_FILE=bug1667758 and hit enter
• Now you need to run Firefox Nightly from within the cmd.exe prompt, by typing (or copy/pasting) the follow command: "c:\Program Files\Firefox Nightly\firefox.exe" and hit enter. Note that the path here should be the path from step 1 where you installed Nightly. Also note that the quotes are required if the path has spaces in it.
• Firefox Nightly should start and load the page from step 3.
• Scroll down until the problem reproduces
• Wait 5 seconds just to make sure all the logs get written to disk
• Close Firefox Nightly
• You can close the cmd.exe window as well

At this point, if you go to user home folder (C:\Users\foo) there should be a bunch of files like bug1667758.child-1.moz_log. Pack all of those files (anything starting with bug1667758) into a zipfile and attach it to this bug.

Thanks!

Comment 11

[Marian]

Attachment: bug1667758-log.zip

Done

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Thanks, that's perfect. From the logs it looks like the animation keeps getting interrupted every now and then, which might explain the issue you're seeing. I'm not sure why this would only happen with shorter mousewheel animations but I can try to reproduce it locally and see if I can make progress that way. If not I might have to bother you again for more logs on a custom build with more logging output.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Actually what I thought was the animation getting interrupted looks like it's just the animation ending between consecutive flicks of the scroll wheel. The scroll position ends up in the right place as far as I can tell from the log. So I made a build with some extra logging that might hopefully shed some more light on the problem.

Can you please download the build here and run through the steps in comment 10 again, using that build? Thanks again!

Comment 14

[Marian]

Attachment: bug1667758-log-2.zip

Done

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Attachment: ScrollPos and Scrolldelta.svg

Thanks. So I went over the log and as far as I can tell everything is behaving pretty normally. The animations are working as intended, and the animation duration varies with the interval between scrollwheel ticks as intended - if you scroll the wheel faster the animation duration goes down. I even graphed the scroll position and mousewheel events vs time as sometimes it's easier to these things visually. I'm attaching the resulting graph. You can see that the scroll position (blue dots) has a steeper slope in places where the mousewheel events (red dots at the bottom) came closer together. I don't see any point at which the position curve "stalls" like I would expect if with some sort of "braking" effect like you described.

Comment 16

[Kartikaya Gupta (email:[e-mail])]

Attachment: bandicam+2020-10-09+21-45-43-726.mp4

Andronachi shared another video on Matrix of this happening which I'm attaching. I can sort of see the issue but it's not totally clear what the cause is. I suspect the "flick" of the mousewheel is sending a spurt of mousewheel events in quick succession, followed by a single "trailing" mousewheel event. This pattern shows up in the graph in the previous comment as well, and has the effect of slowing down the animation towards the end, because of the delay between the last two mousewheel events.

It may be possible to tune the physics a little bit more here but for now I'll marking this S3/P3 as it may be hardware specific as well, and we haven't gotten other reports of this behaviour.

Comment 17

[Marian]

I just play more with 'general.smoothScroll.mouseWheel.durationMaxMS'=1000 and 'general.smoothScroll.mouseWheel.durationMinMS'=30
Is easy to spot the behavior. Any value below of 100 (general.smoothScroll.mouseWheel.durationMinMS) is marking this to appear.

Comment 18

[Marian]

This still happens with different mouse and different system.

Comment 19

[Botond Ballo [:botond]]

Out of curiosity, does setting general.smoothScroll.msdPhysics.enabled to true in about:config help at all?

Comment 20

[Marian]

Yea. Seams much better. No weird jumps

Comment 21

[Marian]

Also, I see this enabled by default on Nightly

Comment 22

[Botond Ballo [:botond]]

Glad to hear it! Marking this as dependent on bug 1760372 where we're planning to make MSD physics the default on the Release channel as well.

Comment 23

[Marian]

Looks like too fast compared how I was usually liked it like the old one.
I think I stick without animations, more better.
And I can read when I scroll.

Comment 24

[Botond Ballo [:botond]]

The MSD physics does have some prefs to customize it, though they are different than the prefs for customizing the old (Bezier) physics. They are under general.smoothScroll.msdPhysics.*.