Several animations are rendered incorrectly on the website

VERIFIED FIXED in Firefox 67



2 months ago
2 months ago


(Reporter: ppop, Assigned: jrmuizel)


(Blocks 1 bug, {regression})

Windows 10
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox65 disabled, firefox66 disabled, firefox67 verified)



(4 attachments, 1 obsolete attachment)

[Affected versions]:

  • Firefox Beta Version 66.0b14, Build ID 20190307095232
  • Firefox Nightly Version 67.0a1, Build ID 20190310214003

[Affected Platforms]:

  • All Windows


  • The "gfx.webrender.all.qualified" boolean pref is set with the "true" value.

[Steps to reproduce]:

  1. Open the browser with the profile from prerequisites and navigate to
  2. Scroll down the page until the "All-screen makes all the difference." section is displayed.
  3. Scroll up to the top of the page and observe the behavior.
  4. Observe the behavior.

[Expected result]:

  • The animation with 3 phones is rendered correctly.

[Actual result]:

  • Parts of the image are cropped and only one phone is displayed.


  • Workaround: Resizing the browser causes the image to render correctly.
  • On the same page, the "Face ID" animation is stuttering while coming into view.
  • I have attached screen recordings of both issues.


2 months ago
Priority: -- → P3

Comment 1

2 months ago

I'm not sure if this is a regression. But if it is a regression window would help. From my initial investigation it looks 3d transforms related.


Comment 2

2 months ago
Posted file Somewhat reduced test case (obsolete) —

Comment 3

2 months ago
Posted file Further reduced
Attachment #9050175 - Attachment is obsolete: true

Comment 4

2 months ago

I think this is probably a blob related issue:

There's no 3d transforms involved in this test case, it's just a mask image.

The mask image is a data uri that is an SVG file. I can reproduce the problem by scrolling down until a new DL arrives, then scrolling back up.

However, if I export that SVG mask image as a PNG file, and modify the HTML file to use the mask image as a PNG, then I can no longer reproduce the problem.

I can dig a bit further, but if that's the case it might be best for someone who knows the blob code to investigate further.

Comment 5

2 months ago

I added some debug logs to the rasterize method in Moz2dBlobRasterizer, which write out the index of the first non-zero byte in the resulting image.

Initially this is at byte 1429. As you scroll down the page and force new display lists (by clicking on the page content), this value remains constant.

At some point, this value starts to change - e.g. about half way down the page, when rasterizing the blob, the first non-zero byte in the rasterized result is at 230678. This corresponds with scrolling up and seeing the mask is partially clipped and drawn incorrectly.

If you continue scrolling down the page to the bottom, and force a new DL to be sent, the rasterized blob image is completely empty (all 0), which corresponds with scrolling up to the top of the page and seeing nothing drawn.

My guess is that this is occurring somewhere around where the display port / view port (?) region is?

Comment 6

2 months ago
Posted image mask.png

Comment 7

2 months ago

Nical, there's probably something going wrong around here: and the problem was perhaps caused by bug 1513772. If you feel like trying to fix it before morning EST that would be wonderful. Otherwise, I'll look at it then.

Flags: needinfo?(nical.bugzilla)

I have retested this issue on older Firefox versions and it seems that it's not reproducible on Nightly 61.0a1. Considering this using the mozregression tool I have found this regression window:

Last good revision: 63988e7c891f8d664f428fbaf91d9b181e3557e1
First bad revision: 0571c2da7c437eb965ebf0cb79a4d991e6d7b8c2

It appears that bug 1460491 caused the issue.

Flags: needinfo?(jmuizelaar)

Comment 9

2 months ago

It looks like this is caused by us not noticing changes to the display list building rect and us using that building rect to clip the image drawing.

Flags: needinfo?(jmuizelaar)


2 months ago
Flags: needinfo?(nical.bugzilla)


2 months ago
Assignee: nobody → jmuizelaar

Comment 10

2 months ago

Previously we would only paint the building area but we
would not do anything to check that the building area had
changed. Since, we're already allocating a surface for the entire
item it's better to just paint it and not worry about doing extra

Originally, we used mVisibleRect here. That was changed to GetPaintRect()
in part 1 of 1460491 and then to GetBuildingRect in part 2. However,
I think the original code was always wrong and we should've been using
mBounds the whole time.

Blocks: 1460491
Has Regression Range: --- → yes

Comment 11

2 months ago
Pushed by
Always paint the entire mask. r=mattwoodrow

Comment 12

2 months ago
Last Resolved: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

I have verified that the main issue is no longer reproducible on Windows 10 x64 using Firefox Nightly Version 67.0a1, Build ID 20190313215409.

However the issue mentioned in the notes is still reproducible and is not part of the same regression that caused the main bug. Should I reopen this issue or file a separate bug to track it ?

Flags: needinfo?(jmuizelaar)

Comment 14

2 months ago

A separate bug please.

Flags: needinfo?(jmuizelaar)

Thanks, I filed a separate bug at 1535342.

You need to log in before you can comment on or make changes to this bug.