Closed Bug 1509295 Opened 5 years ago Closed 5 years ago

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

Categories

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

65 Branch
Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

Attachments

(1 file)

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.
Summary: Scrolling towards 7 o'clock moves the page the way horizontally → Scrolling towards 7 o'clock moves the page the wrong way horizontally
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.
(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?
(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
(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.
Priority: -- → P3
Assignee: nobody → kats

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.

Attachment #9052042 - Attachment description: Bug 1509295 - Clear velocity history when enabling axis locking on an axis. r?botond → Bug 1509295 - Apply axis locking for flings at the start of the fling. r?botond
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2b7718ac0493
Apply axis locking for flings at the start of the fling. r=botond
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: