1714569 - Reddit's menu flashes when scrolling

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: reddit_flash.webm

Reddit is pretty horrible on all the browsers when it comes to checkerboarding.
But in Firefox (linux+wayland+webrender) the white box/menu on the right side flashes too.

Comment 1

[MarjaE]

Seizure warning for the video.

Comment 2

[Jamie Nicol [:jnicol] out of office until 6th Jan]

This doesn't seem to be a recent regression (it reproduces with a several year old build), and I can reproduce with both Basic compositing and webrender. I can also reproduce on both Linux and Windows (I have not tested Mac).

The bottom two boxes on the right hand side are implemented as position: sticky (only one of these is shown in the above video, I presume due to an ad-blocker). And there are some boxes above them which scroll off the screen. If I change the sticky boxes to position: fixed then I can no longer reproduce the flickering.

IIRC the checkerboarding for the main content isn't due to our graphics code painting too slowly, but rather the new content not being added to the page quickly enough in response to scrolling. (Reddit is implementing some form of infinite scroll by adding/removing content)

I wonder if something about position: sticky is getting tripped up by the content being added and removed. Botond, Timothy, any ideas of where to look?

I'm going to hazard a guess this is web painting, but we can always move it again once we've figured out more information.

Comment 3

[Timothy Nikkel (:tnikkel)]

Reddit does some wierd things that basically disable apzc. You have to be careful with reddit because even if you ignore "old reddit" it has two different modes and one of them has overflow: hidden set on the root element and it adjusts the scroll position via js. Generally if you goto reddit.com you'll get the non-overflow hidden version, if you click on a story you'll get the overflow hidden version.

Comment 4

[Timothy Nikkel (:tnikkel)]

There's also several open position sticky bugs in the backlog we haven't had a chance to look into.

Comment 5

[Botond Ballo [:botond]]

A similar bug that's been on file for a while is bug 1539443.

Comment 6

[Botond Ballo [:botond]]

Here's how I would have approached this bug with non-WebRender:

• Use paint dumping (bug 1208661) to see whether the sticky contents are being (a) painted in content and clipped out during composition, or (b) not even painted in content.
  • The paint dumping shows what textures are painted on the client side for each paint, so if we see the sticky element painted during every paint, we know it's (a), otherwise it's (b).
• If it's (a), we can probably spot the problem in the compositor-side layer dumps, looking at the shadow-clip property of the sticky layer. We can then use rr to see how the bad shadow-clip property arises during composition (in AsyncCompositionManager). That may in turn point to various layer properties sent to us by content, so we may need to continue the investigation on the content side.
• If it's (b), we can probably trace the problem to a bad visible rect when painting the contents of the sticky layer, and use rr to see how that visible rect is computed (and particularly, which clips from the display list clip chains affect it).

I'm less sure how to approach the compositor side of this investigation with WebRender / if things like paint dumping have equivalents. Perhaps someone more familiar with WR can chime in on that part.

Comment 7

[Botond Ballo [:botond]]

Here's a different suggestion for how this could be investigated, that's more exploring a theory than methodically tracking down the issue:

Perhaps the issue is that sticky content, which at the display list level is part of the scrolled content of a scroll frame, is clipped by the scroll frame's displayport clip. Fast scrolling moves the displayport and its clip, perhaps enough to checkerboard the scrolled content, but the clip incorrectly affects the sticky content even though it doesn't move.

(With non-WR, a quick way to verify this would be to turn on apz.minimap.enabled=true, and check if the sticky element disappearing corresponds with times when the corresponding area of the viewport is not covered by the displayport (green rect on the minimap).)

At the level of the code, we could try to verify this theory by looking at the compositor side representation of clips ("clip scroll tree" with WR, perhaps?)

Comment 8

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #7)

Perhaps the issue is that sticky content, which at the display list level is part of the scrolled content of a scroll frame, is clipped by the scroll frame's displayport clip. Fast scrolling moves the displayport and its clip, perhaps enough to checkerboard the scrolled content, but the clip incorrectly affects the sticky content even though it doesn't move.

I guess this issue was fixed in bug 1424714. However, I don't have a detailed enough understanding of that fix to say whether e.g. it might have left out some cases that affect Reddit.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

(Though I hadn't noticed this bug) This has been fixed by bug 1730998 (Thanks to the Olli's suggestion in that bug coincidently)