Open Bug 1623566 Opened 4 years ago Updated 4 years ago

Jumpy scrollbar when scrolling contacts section on New Facebook with WebRender

Categories

(Core :: Graphics: WebRender, defect, P3)

Desktop
All
defect

Tracking

()

Tracking Status
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- fix-optional

People

(Reporter: atrif, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(3 files)

Attached image fb_scrtollbar_0.gif

Affected versions

  • 76.0a1 (20200318213346)
  • 75.0b5 (20200317211402)
  • 74.0 (20200309095159)

Affected platforms

  • Windows 10 x64
  • Ubuntu 18.04
  • macOS 10.15

Preconditions

  • click account dropdown and select “Switch to new Facebook”
  • turn webrender on (gfx.webrender.all:true)

Steps to reproduce

  1. Open Firefox and login to Facebook account.
  2. Scroll the contacts list and observe the scroll bar.

Expected result

  • The scroll bar is moving accordingly with no glitches.

Actual result

  • Jumpy scroll bar when scrolling through contacts.

Regression Range

  • I will search for one ASAP if there is one

Notes

  • Attached a screen recording with the issue.
Has Regression Range: --- → no
Has STR: --- → yes

Attaching the regression range. Unfortunately, this is as far as I can go.

Last good revision: d305772af471766618393c01065556e739738e84 (2019-01-28)
First bad revision: 4440fbf71c72e13cfcb6257bbae6024052ffd46d (2019-01-29)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d305772af471766618393c01065556e739738e84&tochange=4440fbf71c72e13cfcb6257bbae6024052ffd46d

Has Regression Range: no → yes

Couldn't reproduce on Mac or Windows 10. It might be related to size of the contacts list.

Priority: -- → P3

(In reply to Miko Mynttinen [:miko] from comment #2)

Couldn't reproduce on Mac or Windows 10. It might be related to size of the contacts list.

Yes, you are right, there has to be a lot of contacts to reproduce.

Hey Kats, can you take a look?

Flags: needinfo?(kats)

I've deleted my regular Facebook account, so I'll have to build a dummy one with sufficient dummy contacts to repro, which might take a while. I looked through the regression range and there's a few patches that might have caused this. Bug 1498639 is the most likely one, I think, although bug 1522264 and bug 1522724 are other possible candidates.

I was able to intermittently reproduce with Jeff's dummy account and a tiny window. It looks like the scrollbar isn't a native scrollbar but a div that they make look like a scrollbar using a variety of perspective/transform CSS properties and whatnot. So it's almost certainly a regression from bug 1498639. Extracting a standalone testcase would be the next order of business. Not sure how easy that will be, since we'll probably need to find the scripts that they're using to update the properties too.

Hm, I tried reproducing today but wasn't able to. It's possible the FB page changed since I tried last, since parts of the div structure look a little different than what I remember. Alexandru, are you still able to reproduce this?

Flags: needinfo?(alexandru.trif)

Also, if you are able to still reproduce: I made a try build (https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=e102b45f49cf95042c53ad41dcd83ca927980775) with d7a369c effectively reverted. Please see if you can still reproduce the problen on the try build as well, as that will help confirm the regression.

Attached image fb_scroll_Wr2.gif

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7)

Hm, I tried reproducing today but wasn't able to. It's possible the FB page changed since I tried last, since parts of the div structure look a little different than what I remember. Alexandru, are you still able to reproduce this?

I can still reproduce the issue using Firefox 76.0a1 (20200330220101) on Windows 10x64.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #8)

Also, if you are able to still reproduce: I made a try build (https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=e102b45f49cf95042c53ad41dcd83ca927980775) with d7a369c effectively reverted. Please see if you can still reproduce the problen on the try build as well, as that will help confirm the regression.

Also with the build from above, the scroll bar no longer shakes but scrolling down makes it disappear. Attached a screen recording. Thank's!

Flags: needinfo?(alexandru.trif)

(In reply to Alexandru Trif, QA [:atrif] from comment #9)

Also with the build from above, the scroll bar no longer shakes but scrolling down makes it disappear. Attached a screen recording. Thank's!

Interesting. Was this the same behaviour you saw when running builds from before the bisection result range? i.e. when you did the bisection, was the "good" behaviour the desired behaviour (scrollbar behaving normally) or was it this "scrolling down makes it disappear" behaviour? Or something else?

Flags: needinfo?(kats) → needinfo?(alexandru.trif)
Attached image fb_scroll_Wr3.gif

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #10)

(In reply to Alexandru Trif, QA [:atrif] from comment #9)

Also with the build from above, the scroll bar no longer shakes but scrolling down makes it disappear. Attached a screen recording. Thank's!

Interesting. Was this the same behaviour you saw when running builds from before the bisection result range? i.e. when you did the bisection, was the "good" behaviour the desired behaviour (scrollbar behaving normally) or was it this "scrolling down makes it disappear" behaviour? Or something else?

Nope, the scrolling bar behaved normally. The screen recording is from the last good known build (2019-01-28) ran with mozregression.

Flags: needinfo?(alexandru.trif)

Great, thank you!

I guess this means that either (a) my attempt at reverting the regression was buggy, (b) the regression is from some other change, not the one I thought, or (c) other changes have landed since the regression range that have also affected this behaviour, and I would need to revert those as well to confirm the regression range.

At any rate, I'll dig into this a bit more to try and understand what's going on.

Parking with me for now.

Assignee: nobody → kats

I can reproduce this reliably today, seems like adding more friends to the test account did the trick. I was able to use builds from archive.mozilla.org to confirm the regression range and narrow it down slightly more to https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d305772af471766618393c01065556e739738e84&tochange=815f7149b30b27f79395d9a0155c1ebeb4fca8b5 - however all the interesting changes I mentioned above are still in this range so it's not super helpful. I tried doing try pushes to create builds and bisect further but apparently taskcluster or treeherder can't deal with that old version of the code... bummer. I don't even want to try building it locally.

I also reproduced on a local build and confirmed that the scrollbar movement is being driven by main-thread repaints, and not by APZ (because it's not a native scrollbar, it's something FB reimplemented). The most likely explanation is just that we're not dispatching scroll events/doing repaints at 60fps so whenever we skip a frame the scrollbar lags behind where it should be and appears to jank/jump. However if that were the case I wouldn't expect such a clear-cut regression range, so there must be some change in that range that affects some relevant codepath here.

Blocks: wr-wild
No longer blocks: wr-76

Kats, do we have a potential fix for this?

Not at the moment. I was having a hard time reliably reproducing the problem and I haven't tried recently. I suspect the real problem here is just "we not doing 60fps" and we need to get a performance profile to see why.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Assignee: kats → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.