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?
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
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]
Whiteboard: [gfx-noted] → [gfx-noted] [platform-rel-Youtube]
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
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?
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.
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.
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.
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]
You need to log in before you can comment on or make changes to this bug.