Markus Stange [:mstange] Reporter
	Description • 8 years ago

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.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 1 • 8 years ago

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?

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 2 • 8 years ago

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.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 3 • 8 years ago

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.

	Markus Stange [:mstange] Reporter
	Comment 4 • 8 years ago

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.

	Botond Ballo [:botond]
	Comment 5 • 8 years ago

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

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 6 • 8 years ago

Yeah that seems reasonable.

	Ben Kelly [:bkelly, not reviewing]
	Comment 8 • 7 years ago

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?

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 9 • 7 years ago

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.

	Ben Kelly [:bkelly, not reviewing]
	Comment 10 • 7 years ago

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.

	(no longer active)
	Comment 11 • 7 years ago

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.

	Ben Kelly [:bkelly, not reviewing]
	Comment 12 • 7 years ago

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.

	Markus Stange [:mstange] Reporter
	Comment 13 • 7 years ago

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

	Naveed Ihsanullah [:naveed]
	Comment 14 • 7 years ago

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.

	Sylvestre Ledru [:Sylvestre]
	Comment 15 • 6 years ago

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

	Sylvestre Ledru [:Sylvestre]
	Comment 16 • 6 years ago

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

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 17 • 6 years ago

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.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 18 • 6 years ago

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