User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Since FF84 nightly WebRender is enabled by default. And for me it has random artifacts/corruption/glitches. This problem was present for a long time, but now when WebRender is default it started to bother me.
OpenGL mode is fine. Detailed information about system and graphics attached.

WebRender corruption example

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

WebRender should have been enabled on your configuration for some time in nightly. It is possible something has changed recently that broke it for you. Does the corruption only happen on popups?

Given it is recent for you (at least getting WR in 84 which is confusing :)), would you be willing to try mozregression to get us a regression window in the last 2 months?
https://mozilla.github.io/mozregression/

Maybe, I'm not using nightly on a permanent basis.
But I'm periodically trying to enable WebRender manually. And every time this problem appears. Last attempt was about 3 months ago. So I think mozregression won't help here, the problem always been here.

P. S. I didn't report earlier because I've just waited for the fix. Experimental features don't have to be stable, you know. But now when I've heard that FF planning to make WebRender as a default option it started to bother me.

Okay, thanks for the explanation :). Currently we are only rolling out to GNOME/X11/Intel+AMD mesa drivers, which as far as I know, this issue has been resolved for them. It is possibly the timing is yet again different typically for KDE users. I'll try installing/using it to reproduce.

And some more info about this question:

Does the corruption only happen on popups?

Sadly, no. This is like overall texture corruption. I've checked it in the texture cache (gfx.webrender.debug.texture-cache). This problem can sometimes corrupt random page elements like font or canvas. And it will still render corrupted until page reload because cached texture itself was corrupted.

This sounds like a different problem than the popup issue then. The texture cache would not be impacted for the issue I was thinking of. This sounds more hardware/driver related.

We use GLX by default. Does this happen with EGL? You can try by setting the environment variable MOZ_X11_EGL=1 and launch firefox.

MOZ_X11_EGL=1

Hmm, seems like it helped.

Hanabishi, is this still reproducible for you? Especially on nightly?

(In reply to Robert Mader [:rmader] from comment #9)

Hanabishi, is this still reproducible for you? Especially on nightly?

For now with nightly 87a1 - yes, GLX still cause artifacts.

Can you update you nightly to the latest one, 88.0a1 (2021-02-27) so it includes bug 1694909 and recheck? Context: bug 1679681 comment 12

(In reply to Robert Mader [:rmader] from comment #11)

Can you update you nightly to the latest one, 88.0a1 (2021-02-27) so it includes bug 1694909 and recheck? Context: bug 1679681 comment 12

Oops, didn't noticed the update. But sadly no, nothing changed in 88a1, still the same artifacts.

(In reply to Hanabishi from comment #12)

Oops, didn't noticed the update. But sadly no, nothing changed in 88a1, still the same artifacts.

Meh, too bad :( But thanks!

Marking as blocked by bug 788319 then.

Try with a recent mesa git-master build or add/create .drirc with

<driconf>
<device driver="radeonsi">
<application name="Firefox" executable="firefox">
<option name="radeonsi_zerovram" value="true" />
</application>
</driconf>

(In reply to walmartguy from comment #14)

Try with a recent mesa git-master build or add/create .drirc with

<driconf>
<device driver="radeonsi">
<application name="Firefox" executable="firefox">
<option name="radeonsi_zerovram" value="true" />
</application>
</driconf>

You have an error here, no closing </device>. But I corrected and applied it.

Well, there are still the same glitchy areas, but now instead of artifacts they are just not rendered and appear as transparent.
So this option obviously removed texture junk from memory, but not fixed the rendering problem itself.

Good to know that EGL will become the default soon. The only complain for me was bug#1712665, but recently it was marked as fixed.

(Darkspirit from bug 1695933 comment 11)

My Debian Testing doesn't have Mesa 21 yet because someone reported a Firefox regression for it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994057

After upgraded libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 libllvm11 to 21.2.1-2, I have artifacts with firefox-esr. For example, with right click on a tab, I can see artifact.
For the moment, I have not seen any problem with other software.

If I downgrade to 20.3.5-1, the problem is no longer present.

https://tracker.debian.org/pkg/mesa
https://packages.debian.org/testing/libegl-mesa0

(Darkspirit from bug 1695933 comment 12)

I replied to the bug and asked for reporting to BMO with a screenshot.
My assumption: The user might have seen intermittent bug 1678804 (bug 1655924/bug 1635153 might be related).
EGL reduces the chance for it to occur, but if one uses slow llvmpipe, it's perfectly reproducible with EGL as well:
$ LIBGL_ALWAYS_SOFTWARE=1 MOZ_X11_EGL=1 firefox-esr

Jan, is this still reproducible for you, especially after bug 1741956 landed? (I don't manage to reproduce with LIBGL_ALWAYS_SOFTWARE=1 on latest nightly)

Closing - we're shipping EGL on all recent drivers where we enable HW-WR. Please reopen if this is still an issue / needs investigation.