Open Bug 1268140 Opened 5 years ago Updated 2 years ago

Momentum scrolling interrupted on YouTube user pages

Categories

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

48 Branch
Unspecified
macOS
defect

Tracking

()

Tracking Status
platform-rel --- +
firefox48 --- wontfix
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- fix-optional
firefox53 --- affected

People

(Reporter: mstange, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [gfx-noted] [platform-rel-Youtube][qf:p3])

Attachments

(2 files)

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.
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?
Whiteboard: [gfx-noted][apz-evangelism]
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.
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.
Depends on: 959793
Attached file 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.
Should this still be [apz-evangelism], given that (IIUC) we're no longer saying the site should change?
Yeah that seems reasonable.
Whiteboard: [gfx-noted][apz-evangelism] → [gfx-noted]
platform-rel: --- → ?
Whiteboard: [gfx-noted] → [gfx-noted] [platform-rel-Youtube]
platform-rel: ? → +
OS: Unspecified → Mac OS X
Priority: -- → P2
Version: Trunk → 48 Branch
Rank: 25
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?
Flags: needinfo?(milan)
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.
Flags: needinfo?(milan)
Whiteboard: [gfx-noted] [platform-rel-Youtube] → [gfx-noted] [platform-rel-Youtube][qf]
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.
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.
Flags: needinfo?(mstange)
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.
I agree with Ben, this is an issue with how APZ processes scroll updates from content. I'd really like us to fix it.
Flags: needinfo?(mstange)
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.
Whiteboard: [gfx-noted] [platform-rel-Youtube][qf] → [gfx-noted] [platform-rel-Youtube][qf:p3]
Keywords: perf
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
Priority: P2 → P3
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
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.
Actually the real work happened in bug 1453425, so adding that as a dep.
Depends on: 1453425
You need to log in before you can comment on or make changes to this bug.