975627 - OS X: Can't scroll right after touchpad swipe

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Jonas H.]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

Go to any site and click on an image that is a link. Go back to the first page by using two-finger slide left on the Macbook touchpad.


Actual results:

Can't scroll using on Macbook touchpad using two fingers. I have to wait a few moments and/or move the cursor in order to be able to scroll again.

Comment 1

[Jonas H.]

Just realized this has nothing to do with images but "works" with any kind of link.

Comment 2

[Drew Willcoxon :adw]

Are you sure it's related to the cursor being over a link?  I can reproduce pretty often by scrolling down, quickly swiping left to go forward in history, and then trying to scroll.  Doesn't matter where the cursor is.  At first I thought it was related to scrolling with inertia, but it happens even with inertia disabled.  I have "Scroll left or right with two fingers" selected for the "Swipe between pages" system preference.

Comment 3

[Jonas H.]

@Drew: Same thing here, didn't try that out earlier. Changed the title accordingly.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Jonas, does this still reproduce for you?

Comment 5

[Jonas H.]

Yes, this is still an issue with Firefox 41 on OSX El Capitan.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Thanks for the reply, Jonas!

Assuming this is something that used to work correctly and you can consistently reproduce the problem, would you be willing to try to help narrow down the cause? If so, we have a tool that automates the process of downloading and launching various older versions so that all you need to do is say whether it's good or bad. The tool is called mozregression and information about it is available at http://mozilla.github.io/mozregression/

A command like |mozregression --good-release 26 --bad-release 27| (or whatever version you remember it working OK with) should make it pretty straightforward.

Having more information about when it broke can make a huge difference for getting a bug in front of the right person, so thanks in advance if you're willing!

Comment 7

[Jonas H.]

Narrowed nightly regression window from [2012-05-01, 2012-05-03] (2 days) to [2012-05-02, 2012-05-03] (1 days) (~0 steps left)
Got as far as we can go bisecting nightlies...
Last good revision: b13bfc70bc44
First bad revision: 807403a04a6a

... attempting to bisect inbound builds (starting from 4 days prior, to make sure no inbound revision is missed)
Getting inbound builds between b5c0d6abf69b and 807403a04a6a
There are no build artifacts on inbound for these changesets (they are probably too old).

Comment 8

[Jonas H.]

To be clear, 2012-05-01 is 'good'.

Comment 9

[Stephen A Pohl [:spohl]]

(In reply to Jonas H. from comment #7)
> Last good revision: b13bfc70bc44
> First bad revision: 807403a04a6a

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b13bfc70bc44&tochange=807403a04a6a

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Thanks, Jonas!

http://hg.mozilla.org/mozilla-central/rev/c70f3a9b31f8 stands out to me as the only obvious scrolling-related change in that range that affects desktop Firefox (there were some Android-only changes in there as well).

Any ideas, Avi?

Comment 11

[Avi Halachmi (:avih)]

Wow... bug from more than a 3 years old patch...

To be honest, I got no clue. I think this was the only time I touched code around these areas, before I even had commit access, and I'm not really familiar with what goes on there, especially after many scrolling changes over the years since it landed.

I'm mostly guessing here, but I think that while the current file still contains remains of the patch of bug 702463 (here http://hg.mozilla.org/mozilla-central/file/tip/layout/generic/nsGfxScrollFrame.cpp ), it's likely to not be in use or go away soon due to both Project Silk and APZ scroll. But again, it's a guess.

I'd say that if it's reproducible and affects a meaningful number of users, then it should be tackled as a new issue by the current maintainer of this code, with the patch at bug 702463 as a possible hint for its cause.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Markus, is this something you'd be able to look at?

Comment 13

[Jonas H.]

I'd be willing to confirm whether this patch is the cause if I there's some way to get a build of that commit and the one before. If it doesn't take a lot of work to familiarize myself with the build process, I'd even be willing to build these myself. Note that I only have a Mac OS X El Capitan machine with GCC and Clang available, but I'm pretty familiar in general with build processes (like make etc).

Comment 14

[Ryan VanderMeulen [:RyanVM]]

To be honest, I have no clue how easy it'd be to build mid-2012 mozilla-central at this point (I'm not horribly optimistic either). If you want to give it a try, https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions can get you started on how to clone mozilla-central and set up a build environment.

Once you have a clone of mozilla-central, the basic gist would be |hg up -C -r 28cfc474ab58|, build & test, |hg up -C -r c70f3a9b31f8|, build & test.

Comment 15

[Markus Stange [:mstange]]

I'm pretty sure this is something that I fixed recently as part of bug 1016035. During swiping, there's this invisible animation running that consumes events. (It's invisible because we never finished the visual part of it...) In bug 1016035, I made us interrupt (or fast-forward) the "animation" as soon as a new scroll gesture starts.

Jonas, can you check whether this is fixed in a recent Nightly?

Comment 16

[Jonas H.]

I can confirm that this is fixed in the 2015-10-27 nightly. Hooray!

Comment 17

[Markus Stange [:mstange]]

Yay!