Momentum scrolling interrupted on YouTube user pages

NEW
Unassigned

Status

()

P3
normal
Rank:
25
3 years ago
12 days ago

People

(Reporter: mstange, Unassigned)

Tracking

({perf})

48 Branch
Unspecified
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(platform-rel +, firefox48 wontfix, firefox49 wontfix, firefox50 wontfix, firefox51 wontfix, firefox52 fix-optional, firefox53 affected)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

3 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.
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]
Created attachment 8748812 [details]
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.
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
(Reporter)

Comment 4

3 years ago
Created attachment 8750440 [details]
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]

Updated

2 years ago
platform-rel: --- → ?

Updated

2 years ago
Whiteboard: [gfx-noted] → [gfx-noted] [platform-rel-Youtube]

Updated

2 years ago
platform-rel: ? → +
status-firefox48: --- → wontfix
status-firefox49: affected → wontfix
status-firefox50: --- → fix-optional
status-firefox51: --- → affected
OS: Unspecified → Mac OS X
Priority: -- → P2
Version: Trunk → 48 Branch

Updated

2 years ago
Rank: 25
Duplicate of this bug: 1280330
status-firefox50: fix-optional → wontfix
status-firefox51: affected → wontfix
status-firefox52: --- → fix-optional
status-firefox53: --- → affected
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.

Comment 11

2 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.
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.
(Reporter)

Comment 13

2 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.
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]
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
You need to log in before you can comment on or make changes to this bug.