Closed Bug 1399495 Opened 2 years ago Closed 2 years ago
Jerkiness while scrolling on Facebook pages
[Note]: - Resize the browser if it's not reproducible on first try [Affected versions]: - Firefox 55.0.3 - Firefox 56.0beta 11 - latest Nightly 57.0a1 [Affected platforms]: - Reproducible across platforms [Steps to reproduce]: 1. Open facebook.com and login 2. Go to a larger page that has several information noted on the right side (eg https://www.facebook.com/BiennaleInterieur/) 3. Scroll the page with mouse or keyboard [Expected result]: - The div from the right side should remain fixed on page [Actual result]: - All the links are shaking and flickering during scrolling, sometimes really visible, sometimes just with a few pixels up/down. https://drive.google.com/file/d/0B7jBNZBM3mz-SHZMNEdOaHJaNHM/view?usp=sharing [Regression range]: - Reproducible all the way back to Firefox 22 so this is not a Firefox regression. This issue might be due to a recent modification on their side. Chrome is not affected.
Can you get a profile on nightly? https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
Sure: https://perfht.ml/2wZzDAi , hope is useful.
Oh, i think I misunderstood. I thought this was jank, but it appears more to be a scroll positioning issue. There is some cycle collection in the profile, but I don't think it would cause what I'm seeing on that page.
A couple of observations: - The jitter happens both with APZ enabled and APZ disabled, but it's smaller with APZ disabled. - The issue seems to be sensitive to factors like the full-zoom and the width of the browser window. That is, sometimes after changing the full-zoom and/or resizing the browser window horizontally, the issue goes away.
The element in question (<div id="u_0_z" class="_2pie">) has "sticky" behaviour without actually using position:sticky: 1) While there is room between the top of the element and the top of the viewport (or more precisely, the bottom of the items fixed to the top of the viewport), the element is position:absolute, with a fixed 'top' value, so that it scrolls with the page. 2) Once the element reaches the top, it switches to being position:fixed, also with a fixed 'top' value, so that it remains visible, fixed to the top of the viewport. This in and of itself is fine - the transition between the two states may not be as smooth as it would be with position:sticky, but otherwise it's fine. The problem is that, under some circumstances (which seem to be affected by full-zoom and browser window width), the page gets confused, and ends up switching rapidly back and forth between state (1) and state (2) even though the element is at the top and you're scrolling downward (so it should just be in state (2) throughout). This is when we observe the jitter.
I can actually reproduce the issue in Chromium as well. The site uses the same technique of switching between fixed and absolute to emulate position:sticky in Chromium, and after enough twiddling with the full-zoom and the page size, I can reproduce the same "confused" state where it switches back and forth between fixed and absolute, and the resulting jitter. It's just maybe harder to get into this state in Chromium than in Firefox. Anyways, this looks like a bug on their side. Moving to Tech Evangelism and cc'ing BenWa.
Component: Panning and Zooming → Desktop
Product: Core → Tech Evangelism
(In reply to Botond Ballo [:botond] from comment #6) > after enough twiddling with the full-zoom and the page size I meant the full-zoom and the browser window size (specifically its width).
I've been looking at this a little bit here and there. The issue is that position:sticky doesn't capture what we want to do. Basically when the right bar is taller than the window and when you scroll down, Facebook wants the right bar to also scroll down. This can happen at any position on the page and doesn't behave like position:sticky. I spent some time but couldn't come up with a way to hack using current CSS to perform this behavior. It also looks like none of the compositor linked scrolling effects style specs have moved forward as far as I can tell.
(In reply to Benoit Girard (:BenWa) from comment #8) > The issue is that position:sticky doesn't capture what we want to do. > Basically when the right bar is taller than the window and when you scroll > down, Facebook wants the right bar to also scroll down. This can happen at > any position on the page and doesn't behave like position:sticky. I spent > some time but couldn't come up with a way to hack using current CSS to > perform this behavior. The issue in this bug isn't that the page is switching between 'fixed' and 'absolute' when the element reaches the top/bottom of the viewport. It's that the page sometimes gets confused about what state the element should be in, and *rapidly* switches between 'fixed' and 'absolute' as you scroll. That doesn't need to happen to achieve the desired effect (e.g. once the element reaches the top, and you keep scrolling down, it can just stay 'fixed'). I get the impression that this rapid switching is a bug related to a rounding error or something.
Ohh right, this one nav part is just wrong. Lets get that fixed. But we do have nav bars that switch from fixed to absolute as you switch the scroll direction and not when you hit the top so it's very noticeable as you change scroll directions.
(In reply to Benoit Girard (:BenWa) from comment #8) > It also looks like none of the compositor linked scrolling effects style > specs have moved forward as far as I can tell. (In reply to Benoit Girard (:BenWa) from comment #10) > But we do have nav bars that switch from fixed to absolute as you switch the > scroll direction and not when you hit the top so it's very noticeable as you > change scroll directions. The work I've been doing in the dependencies of bug 1367770 should make these issues with existing patterns less noticeable. Scroll-linked animations has been on the back burner for a while as we've focused on bringing APZ to more input methods in the lead-up to Firefox 57, but I hope to get back to it once that's wrapped up. That's more of a longer-term effort though.
Found the bug. Looks like it has to do with fractional layout values and rounding. May have a fix out soon.
Assignee: nobody → b56girard
Hello Petruta, Andrei, based on the previous comment I am assuming the work needed on FB side is done by now, could you please check again to see if this bug is still reproducible? Is the jerkiness still as pronounced or has it diminished some? Thanks!
Scrolling on Facebook is considerably improved on every Firefox version, including those that were affected when I reported this issue. There is still some jitter when starting to scroll after modifying browser width, so I'm leaving this bug open for now.
Given the last comment from Softvision, I will consider this now a fix-optional for 57. Please let me know if you disagree. Jim, FYI.
I forgot to update the bug. A fix went out to Facebook production over 2 weeks ago. Thank you for the quality report.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.