1760747 - SVG rendering cut parts when scrolling

Status: RESOLVED FIXED

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

Description

[alejandroalonsofernandez]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36

Steps to reproduce:

In the attached html, scrolling down and up again make part of the svg disappear and appear again.

I'm attaching the sample test.html to reproduce the bug and two screenshots. One for the OK visualization and one for the KO after the scroll.

Actual results:

In my case it only happens when using my laptop screen but not if using an external monitor

Expected results:

The svg should be rendered consistently when scrolling.

Comment 1

[alejandroalonsofernandez]

Attachment: ok.png

Comment 2

[alejandroalonsofernandez]

Attachment: ko.png

Comment 3

[Robert Longson [:longsonr]]

What attached html? There are only png attachments.

Comment 4

[alejandroalonsofernandez]

Attachment: test.html

Comment 5

[alejandroalonsofernandez]

(In reply to Robert Longson [:longsonr] from comment #3)

What attached html? There are only png attachments.

Ops!, I thought I included it when creating the issue but it seems I didn't, it's included now. Thanks! ;)

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 7

[Nicolas Silva [:nical]]

Easily reproduces on nightly and stable. It looks like there is some wrong clipping happening inside of the blob image (paint flashing show tiles for the missing part but they are transparent), and that clip looks like it may be related to the viewport clip. The cut out part comes back when tiles are invalidated and are visible.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cdd6ccd2d2426e1551d31b316086409326f14aa0&tochange=bde3abc2dfe93996e148aef340326e71a14b66a2

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1720986

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

:mattwoodrow, since you are the author of the regressor, bug 1720986, could you take a look?
For more information, please visit auto_nag documentation.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Interestingly enough, reverting bug 1720986 doesn't seem to fix things anymore.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

It would be interesting to see if reverting before and after bug 1728498 makes a difference. nical, do you want to try this? I tried building before then on my M1 but it failed to build because of macOS sdk stuff

Comment 13

[Timothy Nikkel (:tnikkel)]

Reverting bug 1720986 immediately before bug 1728498 fixes the testcase.
Reverting bug 1720986 immediately after bug 1728498 does not fix the testcase.

(Since there we conflicts reverting in the TYPE_FILTER case of PaintContainerItem, it looks like reverting it means not touching the building rect at all there, which is what I did to "revert" after bug 1728498.)

(I don't plan to work on this further, just felt like checking this.)

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gw, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[Glenn Watson [:gw]]

Jeff, perhaps something you or Nical could investigate further?

Comment 17

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1760747. Ensure that the bounds on the geometry of filter items are always limited by the building rect. r?jrmuizel,nical

There are several paths in ComputeGeometryChange where we can allocate an geometry item for a filter item, but only one path that will call DetectContainerLayerPropertiesBoundsChange (which adjusts the bounds for filter items). Make sure this always happens in ComputeGeometryChange.

This was causing a bug where the geometry bounds were the full filter item height on the first paint (even though only part of the filter item was visible inside the building rect), but we did not call DetectContainerLayerPropertiesBoundsChange because it was the first paint where the filter item was visible. Then on the next paint the full filter item was visible, and there is no rect change to signal that we need to repaint.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/12882fe96164
Ensure that the bounds on the geometry of filter items are always limited by the building rect. r=jrmuizel

Comment 19

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/12882fe96164