1268140 - Momentum scrolling interrupted on YouTube user pages

Status: RESOLVED DUPLICATE of bug 1453425

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

Description

[Markus Stange [:mstange]]

STR:
 1. Go to https://www.youtube.com/user/SmoothMcGroove/videos
 2. Scroll around by flinging up and down using a Mac touchpad.

Whenever the "momentum" part of the scroll motion crosses the scroll position threshold at which YouTube changes the header attachment, the scroll is interrupted and the page jumps.

Comment 1

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

This is definitely annoying but I'm not sure how we can fix it. The page is explicitly setting scrollTop and shifting the content in an attempt to do this seamlessly but it doesn't play well with APZ. position:sticky maybe?

Comment 2

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

Attachment: Lightly-edited IRC conversation

Here's an IRC conversation (edited to remove irrelevancies) from last week where Markus proposed a way of solving this problem. To me it seems rather fraught with peril, but deserves more consideration.

Comment 3

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

We talked about this a bit more. We realized that the proposal is equivalent to computing a scroll delta on the main thread scroll change and then just applying that on the APZ side. This is what we wanted to do for scrollBy calls anyway (bug 959793) so we'll implement that first, flush out the bugs, and then see if we need to switch scrollTo to do the same thing.

Comment 4

[Markus Stange [:mstange]]

Attachment: testcase

Here's a testcase that does JS-initiated main thread scrolls using one of three mechanisms, and freezes the main thread for a while after each scroll.

It looks like Safari has the same behavior as we have wrt overriding async scrolls, but they allow momentum scrolls to be continued. Chrome seems to do what I suggested. I haven't tested Edge yet.

Comment 5

[Botond Ballo [:botond]]

Should this still be [apz-evangelism], given that (IIUC) we're no longer saying the site should change?

Comment 6

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

Yeah that seems reasonable.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

FWIW this is really noticeable on the new twitter mobile app.  Its getting a lot of visibility as a good example of a web app being as good as a native app.  Unfortunately our scrolling is terrible when they modify the DOM.  Is there any way we can get this on the schedule to fix?

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Not likely to be done soon, unless QF deems it P1.  I don't know how common this behaviour is, but perhaps the fact that youtube is doing it is enough.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

AFAIK its mainly an android issue.  I realize a lot of focus is on desktop right now, but we are also working on pre-installed deals for android.  This behavior is pretty bad on major sites users are likely to see.

Comment 11

[(no longer active)]

The YouTube case here is suffering from some overpainting issue that bug 1354943 covers.  Markus, do you think this should be P1 otherwise?  I'm inclined to say this is P3, at the lack of evidence that this is otherwise a common issue on the Web.

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

Did you even try mobile twitter?  Try to scroll up while it's adding new tweets to the top of the list.  It's practically unusable due to killing momentum.  I don't understand how paint had anything to do with this.

IMO this is a functional breakage and not a perf issue.

Comment 13

[Markus Stange [:mstange]]

I agree with Ben, this is an issue with how APZ processes scroll updates from content. I'd really like us to fix it.

Comment 14

[Naveed Ihsanullah [:naveed]]

I don't believe this bug is a P1. It is a quick annoyance at best when it occurs. You flick again and can continue. Based on our criteria of would this cause users to leave I don't think anyone would over this. P3.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 17

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

Just a quick note that bug 959793 was landed and turned on recently which should have fixed this class of problems in certain cases. For example, trackpad "momentum" scrolling on mac should not get interrupted by scrollBy calls, whereas it would before. Once that code is more fully baked we can extend it to other scroll mechanisms.

Comment 18

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

Actually the real work happened in bug 1453425, so adding that as a dep.

Comment 19

[Botond Ballo [:botond]]

I expect this has been fixed by bug 1453425 and follow-up work. Please feel free to reopen if not.