1284044 - docs.google.com - Scrolling only works at second attempt

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Toolbar, defect, P5)

Description

[Jens]

I'm the reporter of Bug 1276463. I just recheck today and IMO it is still not 100% fixed. The scrolling on https://docs.google.com/document/d/10kTyCmGPhvZy94F7VWyS-dQ4lsBacR2dUgGTtV98C40/mobilebasic?pref=2&pli=1 does not work at first. Seems like I have to put the focus to the area below the sticky google docs header before scrolling works. That is, only at the *second* attempt the scrolling is working.

See the attached video which compares Firefox Nightly 50.0a1 (2016-07-02) and current Chrome:

At 00:09 with Firefox: After reloading I try to scroll. Does not work
At 00:14 with Firefox: At second attempt the scrolling works.

At 00:30 with Chrome: Scrolling works at *first* attempt and it feels much smoother.

Comment 1

[Jens]

The screencasting video is at https://dl.dropboxusercontent.com/u/94385579/VID_20160703_111952.mp4 (wasn't able to upload to bugzilla)

Comment 2

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

It looks like the page is in a nested scrollable; the first scroll causes some fractional scroll on one of the scrollables and therefore only the second scroll goes to the intended target. We might want to consider doing a handoff right away if the scroll is fractional. I verified setting apz.allow_immediate_handoff to true makes this problem go away, because we allow the handoff to occur.

Comment 3

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #2)
> It looks like the page is in a nested scrollable; the first scroll causes
> some fractional scroll on one of the scrollables and therefore only the
> second scroll goes to the intended target. 

Thanks for the diagnosis!

> We might want to consider doing a
> handoff right away if the scroll is fractional.

Indeed. Here's an outline of how we could do that:

  - In InputBlockState, maintain a scroll delta alongisde mScrolledApzc
    that starts off as zero.

  - In AttemptScroll(), when we would call SetScrolledApzc(), instead
    increment the delta by adjustedDisplacement, and only call
    SetScrolledApzc() if the resulting delta crosses some threshold.

    (Note that we can't require adjustedDisplacement itself to be
    greater than some threshold, because the hardware could be
    sending a touch-move event for every fractional pixel of motion, in 
    which case adjustedDisplacement would never be greater than out
    threshold, but the cumulative amount we scroll could be.)

Comment 4

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

Randall said that the content frame is 1.5 pixels too large on this page, so the "threshold" we would need to have to make this work is at least that much. Because it's not just a subpixel value I'm not as convinced that this is worth fixing anymore.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

I think we'd be best off spending time to figure out why it's 1.5 pixels off rather than changing the scroll behavior. Assuming it's not 1.5px off in Chrome, that is.

Comment 6

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 7

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.