1331194 - mouse scroll slow when key pressed

Status: VERIFIED FIXED

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

Description

[nobounds]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

go to any webpage which is log enough to be scrolled
press any keyboard button/s and hold them pressed
while the buttons are pressed, try to scroll up/down with the mouse wheel

Windows 10 x64 (Ver 1607,Build 14393.693) Firefox 50.1.0. ; Keyboard Steelseries Apex M500  (machanical), Mouse Logitech Daedalus Apex G303;


Actual results:

mouse scrolling is not smooth, and is seemingly slower, than in case when no keyboard button is pressed.


Expected results:

the scrolling speed/smoothness does not depent on whether any keyboard key is pressed or not.

Comment 1

[Tooru Fujisawa [:arai]]

which keyboard button do you press for example?
also, can you provide an example page that the issue happen?

Comment 2

[nobounds]

(In reply to Tooru Fujisawa [:arai] from comment #1)
> which keyboard button do you press for example?
> also, can you provide an example page that the issue happen?
any letter key (i.e. "w", "e", "g", "l","u"..), any numpad key, any number key, any F-Key 
example site.. http://math.stackexchange.com/questions/336622/analytic-geometry-high-school-why-is-the-sum-of-the-distances-from-any-point
practically any web page where you can scroll

Comment 3

[nobounds]

i connected another keyboard to my pc - same behavior.
i tried with another browsers (opera, chrome, seamonkey) the problem didn't occur there.

Comment 4

[Tooru Fujisawa [:arai]]

I cannot reproduce the issue on OSX, with Firefox 50.1.0 clean profile, holding "w" key and scroll by mouse or trackpad on the page in comment #2.
might be platform specific issue.

Comment 5

[nobounds]

i *cannot* reproduce it with 50.1.0 on windows 7 x64.

Comment 6

[nobounds]

A friend of mine could confirm the issue on his system: Windows 10 x64 (10.0.14393 Build 14393), FF 50.1.0

Comment 7

[Ciprian Muresan [:cmuresan], Ecosystem QA]

User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID 	20170117030218

I have managed to reproduce the issue on the latest Firefox release (50.1.0) and on the latest Nightly (53.0a1). I went in about:support, held the "z" key and started scrolling up and down, to me it doesn't seem like it's scrolling slower, it seems like the amount of lines that are scrolled  are less.

The issue is not reproducible with layers.async-pan-zoom.enabled;false.

Comment 8

[Botond Ballo [:botond]]

I see this on Linux as well.

Comment 9

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

What's happening is that holding down a keyboard key sends keypress events to APZ, which keeps breaking the wheel transaction [1]. That in turn causes wheel events to frequently start new wheel blocks which cancels existing animations [2]. Since the wheel events are doing smooth scrolling, each scroll animation makes very little progress before getting cancelled and replaced by a new animation.

[1] http://searchfox.org/mozilla-central/rev/30fcf167af036aeddf322de44a2fadd370acfd2f/gfx/layers/apz/src/APZCTreeManager.cpp#1144
[2] http://searchfox.org/mozilla-central/rev/30fcf167af036aeddf322de44a2fadd370acfd2f/gfx/layers/apz/src/InputQueue.cpp#244

Comment 10

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

Removing the line at http://searchfox.org/mozilla-central/rev/30fcf167af036aeddf322de44a2fadd370acfd2f/gfx/layers/apz/src/InputQueue.cpp#244 fixes the problem, because it allows the animation to keep running. However I'm not sure if that's the right fix. gtests pass, but that it might be that we want to keep cancelling non-wheel animations there.

Comment 11

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

I think keeping just the wheel animations there is probably safer, since it affects a narrower set of codepaths.

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fed133eb1349dc9ff8e020472c3fb7c0c66303c2

Comment 12

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

Attachment: Bug 1331194 - Don't cancel wheel-scroll animations when starting a new wheel block.

Review commit: https://reviewboard.mozilla.org/r/106702/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/106702/

Comment 13

[Botond Ballo [:botond]]

Comment on attachment 8829695 [details]
Bug 1331194 - Don't cancel wheel-scroll animations when starting a new wheel block.

https://reviewboard.mozilla.org/r/106702/#review108018

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3577c257fabe
Don't cancel wheel-scroll animations when starting a new wheel block. r=botond

Comment 15

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/3577c257fabe

Comment 16

[Gerry Chang [:gchang]]

Too late for 51. Mark 51 won't fix.
Hi :kats,
Do you think this is worth uplifting to aurora at least if the patch is not too risky?

Comment 17

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

Sure. Marking wontfix for 52 since I don't think it's worth a beta uplift.

Comment 18

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

Comment on attachment 8829695 [details]
Bug 1331194 - Don't cancel wheel-scroll animations when starting a new wheel block.

Approval Request Comment
[Feature/Bug causing the regression]: APZ
[User impact if declined]: if the user holds down a keyboard key while wheel-scrolling, the wheel scroll is much slower
[Is this code covered by automated tests?]: not really
[Has the fix been verified in Nightly?]: not explicitly
[Needs manual test from QE? If yes, steps to reproduce]: yes. STR in comment 0
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not particularly
[Why is the change risky/not risky?]: made the patch affect as few codepaths as possible. it's also fairly contained, and in code that's well understood.
[String changes made/needed]: none

Comment 19

[Gerry Chang [:gchang]]

Comment on attachment 8829695 [details]
Bug 1331194 - Don't cancel wheel-scroll animations when starting a new wheel block.

Fix a mouse scrolling issue while key pressed and was verified. Aurora53+.

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/76e8397a0bda

Comment 21

[Emil Ghitta, QA [:emilghitta]]

I’ve reproduced the issue described in comment 0 using an affected build: Firefox Nightly 53.0a1(Build Id:20161208075029).

I have verified that the issue is not reproducible using Firefox 53.0b1(Build Id:20170307064827) and Firefox 54.0a2(Build Id:20170309004016) using Windows 10 64bit and Ubuntu 16.04 64bt.