Bug 1458653 Comment 25 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I've compared our code and Chrome's code for fling acceleration (called "fling boosting" in Chrome).

Here's how the behaviors differ:
 - In Firefox, when the finger is lifted and a fling is initiated from the current scroll gesture, the following criteria determine whether fling boosting should be applied:
    - Did less than 750ms elapse between the last fling and this fling?
    - Is this fling pointed in the same direction as the last fling?
 - In Chrome, [the criteria](https://source.chromium.org/chromium/chromium/src/+/master:ui/events/blink/fling_booster.cc;l=158-215;drc=84cf85ac759fedf96ddd050b88e4d8759a9054c4) are very different. Chrome does not take into account the time that has elapsed between the two flings. Instead, the criteria are:
    - Was the velocity of the previous ongoing fling, at the point of interruption, higher than a certain threshold?
    - Is the new fling starting velocity also higher than that threshold?
    - Did the velocity of the current scroll gesture never fall below a certain (different) threshold?
    - Did no more than 50ms elapse since the last touchmove?
    - Is this fling pointed in the same direction as the last fling?
    - (A few others: same source device, no modifier keys pressed)

I will try to implement something that's closer to the Chrome model. In particular, I think it's very important to take into account the scroll velocity at the time the previous fling was interrupted.
I've compared our code and Chrome's code for fling acceleration (called "fling boosting" in Chrome).

Here's how the behaviors differ:
 - In Firefox, when the finger is lifted and a fling is initiated from the current scroll gesture, the following criteria determine whether fling boosting should be applied:
    - Did less than 750ms elapse between the last fling and this fling?
    - Is this fling pointed in the same direction as the last fling?
 - In Chrome, [the criteria](https://source.chromium.org/chromium/chromium/src/+/master:ui/events/blink/fling_booster.cc;l=158-215;drc=84cf85ac759fedf96ddd050b88e4d8759a9054c4) are very different. Chrome does not take into account the time that has elapsed between the two flings. Instead, the criteria are:
    - Was the velocity of the previous ongoing fling, at the point of interruption, higher than a certain threshold?
    - Is the new fling starting velocity also higher than that threshold?
    - Did the velocity of the current scroll gesture never fall below a certain (different) threshold?
    - Did no more than 50ms elapse between any two subsequent touch events during the current scroll gesture?
    - Is this fling pointed in the same direction as the last fling?
    - (A few others: same source device, no modifier keys pressed)

I will try to implement something that's closer to the Chrome model. In particular, I think it's very important to take into account the scroll velocity at the time the previous fling was interrupted.
I've compared our code and Chrome's code for fling acceleration (called "fling boosting" in Chrome).

Here's how the behaviors differ:
 - In Firefox, when the finger is lifted and a fling is initiated from the current scroll gesture, the following criteria determine whether fling boosting should be applied:
    - Did less than 750ms elapse between the last fling and this fling?
    - Is this fling pointed in the same direction as the last fling?
 - In Chrome, [the criteria](https://source.chromium.org/chromium/chromium/src/+/master:ui/events/blink/fling_booster.cc;l=158-215;drc=84cf85ac759fedf96ddd050b88e4d8759a9054c4) are very different. Chrome does not take into account the time that has elapsed between the two flings. Instead, the criteria are:
    - Was the velocity of the previous ongoing fling, at the point of interruption, higher than a certain threshold?
    - Is the new fling starting velocity also higher than that threshold?
    - Did the velocity of the current scroll gesture never fall below a certain (different) threshold?
    - Did no more than 50ms elapse between any two subsequent touch events during the current scroll gesture?
    - Is this fling pointed in the same direction as the last fling?
    - (A few others: same source device, no modifier keys pressed)

I will try to implement something that's closer to the Chrome model. In particular, I think it's very important to take into account the fling velocity at the time the previous fling was interrupted.

Back to Bug 1458653 Comment 25