1509295 - Scrolling towards 7 o'clock moves the page the wrong way horizontally

Status: RESOLVED FIXED

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

Description

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

I see this a lot, not a recent regression, but I never filed it. On fennec if I'm at the rightmost edge of a page (that's scrollable on both axes) and move my finger towards 7 o'clock (down and slightly to the left) then the page moves up (correct) and slightly to the left (wrong). It's quite noticeable if you're at the rightmost edge of the page because you end up drifting away from the edge.

Comment 1

[Botond Ballo [:botond]]

Does the incorrect movement happen during the pan or the fling?

I can't seem to reproduce this when there's room to scroll upwards, but I occasionally get a small fling to the left when doing the 7 o'clock movement in a page's top-right corner.

Comment 2

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #1)
> I occasionally get a small fling to the left when doing the 7 o'clock movement
> in a page's top-right corner.

Here's an example sequence of (timestamp, x-position) pairs going into the velocity tracker when this happens:

(2694572, 514.000000)
(2694591, 509.000000)
(2694607, 508.000000)
(2694625, 500.000000)
(2694642, 500.000000)
(2694659, 500.000000)
(2694675, 500.000000)
(2694692, 500.000000)
(2694708, 500.000000)

The timestamps are monotonically increasing - that's fine. The x-positions are nondecreasing (consistent with a 7 o'clock movement), but in the last several data points, they're the same.

The velocity tracker spits out a velocity of +96 pixels/second, i.e. it seems to conclude your finger is (going to be) moving to the right (and therefore we fling to the left).

I guess, since the x positions started by decreasing, and then stayed constant, it's predicting that they must be about to start increasing?

Comment 3

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #2)
> The x-positions are nondecreasing (consistent with a 7 o'clock movement)

er, s/nondecreasing/nonincreasing

Comment 4

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

(In reply to Botond Ballo [:botond] from comment #1)
> Does the incorrect movement happen during the pan or the fling?

During the fling.

> I can't seem to reproduce this when there's room to scroll upwards, but I
> occasionally get a small fling to the left when doing the 7 o'clock movement
> in a page's top-right corner.

I see this too, and it's probably the same root cause as comment 0. At least it seems quite similar in terms of observed behavior vs. what I would expect to happen.

I'm not able to reproduce my issue in Chrome. The top-left corner variant doesn't manifest either, but that might be because the pull-to-refresh gesture is eating the event and not letting it be used for scrolling at all.

Comment 5

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

Initial investigation seems to indicate that even though X-coordinate of my finger is strictly decreasing (moving right to left across the screen), we axis-lock the x-axis partway through the movement. So the AndroidVelocityTracker ends up with a history where the first few positions are decreasing and then the next lot are identical (due to axis locking). So then the ComputeVelocity code presumably computes a polynomial where the "next velocity" is going the other way, and that's what gets used in the fling.

Will think about a good way to fix this.

Comment 6

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

Attachment: Bug 1509295 - Apply axis locking for flings at the start of the fling. r?botond

Comment 7

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

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=30674e84f7bd823153deedc46eeb4da28d807955

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2b7718ac0493
Apply axis locking for flings at the start of the fling. r=botond

Comment 9

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/2b7718ac0493