[Affected versions]:
Nightly 77.0a1

[Affected platforms]:
Platforms: Windows 10

Preconditions:
Verify about:support and check Compositing = WebRender
if it's not enabled reach about:config and set gfx.webrender.all = true

Steps :

1. Open the Firefox Browser and reach https://www.miragefestival.com/
2. Scroll a bit up and down and watch the bottom of the first mirage (the one with the pink lines).

Expected Results :
There should be no graphical issues displayed.

Actual Results :
White flicker is displayed at the bottom of the first mirage when scrolling up or down.
This issue only occurs with WebRender on.
This issue occurs on Laptops as well as Desktops with Nvidia or Intel GPU's.

Rares, is gfx.webrender.compositor on as well when this issue happens? Can you reproduce it in release or just Nightly?

I can repro this on my mac, so probably not compositor related.

Andrew, could this be a snapping thing?

This issue occurs with both gfx.webrender.compositor = true/false.
With gfx,webrender.force-disabled = true this issue does not reproduce.

I believe so, there are two canvases with fractional heights at the boundary where the white line flashes.

The original site has changed, but the Web Archive has a snapshot this still reproduces.

Yep they moved it, you can find it here as well : http://www.miragefestival.com/2020/ weirdly enough on some laptops, I was unable to reproduce it, on others it can still be seen as well as on the desktops we have.

I have a prototype working now, where we generate the transform needed for canvas (or any async image pipeline iframes really) during scene building instead of display list building. This is because we need the snapped sizes from scene building to properly calculate the transform. This fixes the white line issue for me. Putting together the final patch and tests now.

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

When a transform depends on the layout size of an element, one can see
visual distortions caused by the difference between the unsnapped size
used in the transform, and the snapped size calculated during scene
building. Ideally we could compute the transform after we snap, rather
than before. This patch adds support for a computed reference frame
which takes parameters to calculate the ideal transform dynamically.

In a future patch, we should make videos take advantage of this same
mechanism to avoid similar problems. This requires support for mirroring
and rotations.

https://hg.mozilla.org/mozilla-central/rev/da69b8391ceb

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Marking 78 as affected but this can ride the trains.

This issue is verified as fixed in our latest Nightly build as well as Beta 79.0b3 on Windows 10.