Petruta Horea [:phorea], Desktop QA Reporter
	Description • 7 years ago

[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.

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

Can you get a profile on nightly?

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

	Petruta Horea [:phorea], Desktop QA Reporter
	Comment 2 • 7 years ago

Sure: https://perfht.ml/2wZzDAi , hope is useful.

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

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.

	Botond Ballo [:botond]
	Comment 4 • 7 years ago

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.

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

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.

	Botond Ballo [:botond]
	Comment 6 • 7 years ago

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.

	Botond Ballo [:botond]
	Comment 7 • 7 years ago

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

	Benoit Girard (:BenWa) Assignee
	Comment 8 • 7 years ago

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.

	Botond Ballo [:botond]
	Comment 9 • 7 years ago

(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.

	Benoit Girard (:BenWa) Assignee
	Comment 10 • 7 years ago

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.

	Botond Ballo [:botond]
	Comment 11 • 7 years ago

(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.

	Benoit Girard (:BenWa) Assignee
	Comment 12 • 7 years ago

Found the bug. Looks like it has to do with fractional layout values and rounding. May have a fix out soon.

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 13 • 7 years ago

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!

	Petruta Horea [:phorea], Desktop QA Reporter
	Comment 14 • 7 years ago

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.

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 15 • 7 years ago

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.

	Benoit Girard (:BenWa) Assignee
	Comment 16 • 7 years ago

I forgot to update the bug. A fix went out to Facebook production over 2 weeks ago. Thank you for the quality report.