1143904 - [Panning and Zooming][Overscroll]Scrolling back during overscroll results in strange animation behavior, appears to get temporarily stuck

Status: RESOLVED INCOMPLETE

(Core :: Panning and Zooming, defect)

Description

[Martin Shuman [:Marty]]

Attachment: logcat-overscroll.txt

Description:
If the user slowly scrolls back a small amount before releasing an overscroll, the overscroll animation will appear sluggish, and seem to get stuck, before finally bouncing back to normal appearance.  The momentum from the backwards movement appears to be maintained until the velocity reaches zero, and then the animation finally snaps back.

Repro Steps:
1) Update a Flame to 20150316010202
2) Scroll down on the home screen to activate the overscroll effect. Do not release the overscroll.
3) Slowly scroll back a small amount, and then release the scroll.

Actual:
The stretched overscroll appears to get stuck before bouncing back to the normal, non-stretched appearance.

Expected:
The overscroll bounces back to normal immediately after releasing the overscroll.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150316010202
Gaia: 4868c56c0a3b7a1e51d55b24457e44a7709ea1ae
Gecko: 436686833af0
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Repro frequency: 5/5
See attached: video (URL), logcat

Comment 1

[Martin Shuman [:Marty]]

This issue DOES occur on Flame 2.2 builds.
The stretched overscroll appears to get stuck before bouncing back to the normal, non-stretched appearance.

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150316002502
Gaia: a6b2d3f8478ec250beb49950fecbb8a16465ff6f
Gecko: 18619f8f6c5c
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

--------------------------------------------------------------

This issue does NOT occur on Flame 2.1 builds.
The current overscroll effect is not implemented on 2.1 builds.

Comment 2

[Peter Bylenga [:PBylenga]]

NI on No-Jun for nomination decision and assignment.

Comment 3

[Botond Ballo [:botond]]

What's happening here is that even if a fling animation starts in an overscrolled state, as long as it's not moving in the direction where it would increase overscroll, we allow it to complete before (possibly, if we're still overscrolled when it ends) starting an overscroll animation.

We could change the behaviour so that if a fling animation starts in an overscrolled state, we always switch to an overscroll animation right away, but this would have an undesirable effect: when a fling starts in an overscrolled state with a large velocity in the direction of relieving overscroll, then rather than allowing that large velocity to relieve overscroll **and then continue flinging the page in the other direction**, we would just run the overscroll animation to relieve overscroll and stop.

To put it another way, right now if you pan into overscroll a bit, and then flick determinedly in the other direction (with your finger leaving the page while still in overscroll), you will succeed in scrolling the page in that other direction, but with the potential fix I described, you wouldn't.

It seems to me that the underlying issue is that in our physics model, we don't distinguish between the following two sources of a velocity in the direction that relieves overscroll:

  - The velocity created by the spring snapping back. We don't want to allow this
    velocity to start scrolling the page in the opposite direction. Instead, once
    the spring's resting position is reached, the spring force kicks in "in reverse"
    to create an oscillating movement, which is dampened to eventually stop.

  - A pre-existing velocity, such as from a fling. We *do* want to allow this
    velocity to start scrolling the page in the opposite direction, if it's
    large enough to not be counteracted by friction by the time the spring reaches
    its resting state.

Gordon, do you have any suggestions for how we could adjust our physics model to address this?

Also cc'ing Chris, who tends to have insightful ideas about overscroll UX :)

Comment 4

[No-Jun Park [:njpark]]

I can repro the issue as well, but to me this is not a urgent blocker issue because it does not appear to be seriously degrading the user experience, and it looks like it's not quite that easy to repro in a normal scenario.

Comment 5

[Botond Ballo [:botond]]

cc'ing Markus as well. Mac overscroll may not be affected by the same issue, because momentum scrolling on Mac isn't modeled as an animation, but it's probably good to be aware of it.

Comment 6

[Botond Ballo [:botond]]

The problem described in comment 3 is still relevant, but I now have a plan for how to fix it (and many other things): bug 1282245, so I'm happy to leave this closed and have that bug supersede this.