1714483 - Firefox GUI graphics error (partly transparent) if FXAA has been manually enabled in NVIDIA X Server Settings (Antialiasing)

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Gue]

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

Steps to reproduce:

updated to Firefox 89 on Linux Mint

Actual results:

after update to Firefox 89 on Linux Mint Firefox GUI is no-more usable

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Gue]

Attachment: Firefox.png

Comment 3

[Gue]

Remark: there were other updates on my computer too. (e.g. the nvidia-graphics-drivers-460)
but, as all other programs which I tested worked as normal, I'm quite sure, that the bug is somehow related to Firefox 89

Comment 4

[Min]

I'm experiencing the same issue. My environment:
OS: Linux Mint 20.1
Firefox: 89.0+linuxmint1+ulyssa
GPU: GeForce GTX 950
NVIDIA driver: 460.73.01

Firefox's entire interface seems as though it's been blended with the desktop. Firefox 88 did not have this issue. I've tried several other programs that use hardware acceleration (Chrome, glxgears, etc.) and none of them are having any problems.

If I start Firefox in safe mode, it seems fine, but restarting Firefox normally (even after refreshing Firefox) still experiences the problem.

Comment 5

[Min]

Minor update: Going into Firefox's Settings and unchecking "Use hardware acceleration when available" makes Firefox usable again, although obviously this is not ideal.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Thanks, that's really useful. Is it possible that any of the affected people could run a regression range (should take about 15 minutes)?

pip3 install --user mozregression, then mozregression --good 88 --bad 89 would help. Also, if you could attach the about:support information to the bug would be super helpful. Thanks!

Comment 7

[Gue]

first, many thanks for trying to resolve this issue (which seems to affect only some special configurations?)!
I ran the mozregression,
result was: both good; with the final statement: ERROR: Build was to be expected bad! The initial good/bad range seems to be incorrect.
Remark: after the initial issue with FIrefox 89 I've restored the last working configuration (rollback of Firefox, Nvidia driver, and other changes)
I can take a Timeshift-snapshot and try installing Nvidia and Firefox update again if this would help

Comment 8

[Gue]

Attachment: firefox about support.txt

about:support from Firefox 88

Comment 9

[Min]

I'm not sure mozregression is working as expected for me. When I run it, it seems like it's downloading Firefox 89 as what it expects to be its "good" build. When it runs, I experience the rendering issue, and when I say it's "bad", it exits. Here's the output:

$ mozregression --good 88 --bad 89
**********
You should use a config file. Please use the --write-config command line flag to help you create one.
**********

 0:01.85 INFO: Using date 2021-04-19 for release 89
 0:02.36 INFO: Using date 2021-03-22 for release 88
 0:02.77 INFO: Testing good and bad builds to ensure that they are really good and bad...
 0:02.77 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2021/03/2021-03-22-17-46-41-mozilla-central/firefox-89.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
 0:03.97 INFO: Running mozilla-central build for 2021-03-22
 0:12.81 INFO: Launching /tmp/tmpfcu37aqg/firefox/firefox
 0:12.81 INFO: Application command: /tmp/tmpfcu37aqg/firefox/firefox -profile /tmp/tmpfply5hor.mozrunner
 0:12.81 INFO: application_buildid: 20210322174641
 0:12.81 INFO: application_changeset: 7bff3dc37b071d5272e2d445a0bfcbe21aabd38d
 0:12.81 INFO: application_name: Firefox
 0:12.81 INFO: application_repository: https://hg.mozilla.org/mozilla-central
 0:12.81 INFO: application_version: 89.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): bad
 0:21.67 ERROR: Build was expected to be good! The initial good/bad range seems incorrect.

Anyway, if I widen the window and go back to --good 86, that works, and after stepping through many different versions, it eventually prints this:

 4:03.95 INFO: Narrowed integration regression window from [8471b70b, 567347cd] (3 builds) to [8471b70b, 12744d62] (2 builds) (~1 steps left)
 4:03.95 INFO: No more integration revisions, bisection finished.
 4:03.95 INFO: Last good revision: 8471b70b4df960d3599dcd951f0b05fb4f7bd420
 4:03.95 INFO: First bad revision: 12744d62ec8944fe64bb028a68bcab2c4665cf7b
 4:03.95 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8471b70b4df960d3599dcd951f0b05fb4f7bd420&tochange=12744d62ec8944fe64bb028a68bcab2c4665cf7b

Comment 10

[Min]

Attachment: about:support from Firefox 89 (hardware acceleration disabled)

Comment 11

[Gue]

Update: I've re-installed both Firefox 89.0 (64bit), and nvidia-graphics-drivers-460, and everything works fine now. strange, but good...
running Firefox with hardware graphics acceleration (if available)

Comment 12

[Min]

Another potential note of interest here is that I'm using NVIDIA's CUDA drivers, both because I do CUDA development and because I experience occasional display freezes when using the official Ubuntu drivers.

$ apt-cache policy nvidia-driver-460
nvidia-driver-460:
  Installed: 460.73.01-0ubuntu1
  Candidate: 460.73.01-0ubuntu1
  Version table:
     460.80-0ubuntu0.20.04.2 500
        500 http://archive.ubuntu.com/ubuntu focal-updates/restricted amd64 Packages
        500 http://security.ubuntu.com/ubuntu focal-security/restricted amd64 Packages
 *** 460.73.01-0ubuntu1 600
        600 http://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  Packages
        100 /var/lib/dpkg/status
     460.32.03-0ubuntu1 600
        600 http://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  Packages
     460.27.04-0ubuntu1 600
        600 http://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  Packages
        600 http://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  Packages
        600 http://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  Packages

Comment 13

[Min]

One more update; I wasn't running the latest major release of the CUDA driver (465.19.01), so I updated to test it, and Firefox is still broken in the same way.

Comment 14

[Min]

I made another interesting discovery; it appears the problem is caused by globally enabling FXAA in the nvidia driver settings. I had previously enabled it to force it on for an application that didn't let me control it for just that application. After disabling it, I no longer have any problems with the latest build. For reference: https://i.stack.imgur.com/U3NR0.png

Comment 15

[Gue]

on my computer FXAA is turned on, but no problems with the new installation of Firefox 89
to be honest, I've no idea what has changed since I had these issues 2 days ago.
NVIDIA driver version is now 450.119.03

Comment 16

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

Thank you for the information, Gue and Min.

Andrew, do we need to block webrender on a certain nvidia driver version here? Or can we detect if FXAA is enabled and block in that case?

Comment 19

[q3.max.2011]

After another update it is now broken even without FXAA enabled, how can this be debugged?

Comment 22

[Robert Mader [:rmader]]

Erik, do you know if there's something we can do here in Firefox (or you on the driver side?). Thanks!

P.S.: the common issue between this bug and its duplicates appears to be that turning on FXAA breaks FF HW rendering.

Comment 23

[Erik Kurzinger]

We do have the environment variable __GL_ALLOW_FXAA_USAGE=0 which is meant to override global FXAA enablement for individual applications.

Comment 24

[Erik Kurzinger]

I brought this up internally at NVIDIA. We provide a mechanism in our driver to apply certain settings for specific applications based on a json file https://download.nvidia.com/XFree86/Linux-x86_64/470.57.02/README/profiles.html and we agreed it would make sense to disable FXAA for firefox in the default configuration. FXAA really isn't expected to work well with something like a web browser anyway. Note that the environment variable mentioned in my last comment can serve as a work-around for the time being, but the app-profile solution will likely provide a better user experience.

Comment 25

[Robert Mader [:rmader]]

(In reply to Erik Kurzinger from comment #24)

I brought this up internally at NVIDIA. We provide a mechanism in our driver to apply certain settings for specific applications based on a json file https://download.nvidia.com/XFree86/Linux-x86_64/470.57.02/README/profiles.html and we agreed it would make sense to disable FXAA for firefox in the default configuration. FXAA really isn't expected to work well with something like a web browser anyway. Note that the environment variable mentioned in my last comment can serve as a work-around for the time being, but the app-profile solution will likely provide a better user experience.

Thanks for looking into it Eric!

Not FF related side note: there may be limits to the app-profile approach - GTK4 applications use GL rendering by default as well and a bunch of them currently get ported from GTK3, some of them coming with the next Gnome version this autumn. While GTK could set the env variable, it may make sense to:

• figure out some heuristic to disable the feature for "non-game" applications
• make FXAA work better for such apps
• provide a allow list instead of a block list - this is AFAIK how mesa deals with such features, notably mesa_glthread

Comment 27

[Darkspirit]

In case many ESR users (who are now getting WebRender) run into this,
__GL_ALLOW_FXAA_USAGE=0 env var could possibly be set after this GLX/Mesa env var:
https://searchfox.org/mozilla-central/rev/2aa1094a66cb967a5eaa38c163ecf874c22a0501/gfx/gl/GLContextProviderGLX.cpp#80

Comment 28

[Darkspirit]

Attachment: 2021-09-15 23-46-51.mp4

Ubuntu 21.04, GTX 1060
Attached screencast: Text becomes blurry with Nvidia driver 470.63.01 and EGL (bug 1695933 = MOZ_X11_EGL=1).

With gfx.x11-egl.force-disabled=true (=GLX) the whole window still becomes entirely white.

I can confirm that __GL_ALLOW_FXAA_USAGE=0 ./firefox fixes the problem.

A freshly installed Chromium (sudo apt install chromium-browser which installed a chromium snap) did not suffer from FXAA.

Comment 29

[Darkspirit]

(Darkspirit from comment #28)

A freshly installed Chromium did not suffer from FXAA.

Should PR_SetEnv("__GL_ALLOW_FXAA_USAGE=0"); be set for MOZ_X11_EGL and GLX (or entirely for Linux) or this bug be wontfixed?

Comment 30

[Robert Mader [:rmader]]

(In reply to Darkspirit from comment #29)

(Darkspirit from comment #28)

A freshly installed Chromium did not suffer from FXAA.

Should PR_SetEnv("__GL_ALLOW_FXAA_USAGE=0"); be set for MOZ_X11_EGL and GLX (or entirely for Linux) or this bug be wontfixed?

Yes, doesn't really hurt to set it. I'll prepare a patch.

Comment 31

[Robert Mader [:rmader]]

Attachment: Bug 1714483 - Force-disable Nvidia FXAA, r=aosmond

While not enabled by default, it is openly exposed in the driver
settings and thus apparently not uncommon. Currently it causes
significant glitches for Firefox HW-WR, but also other text focused
apps (GTK 4).
While this should get fixed in the driver eventually, use the
workaround recommended by Nvidia to force-disable it for now.

Comment 32

[Robert Mader [:rmader]]

Try: https://treeherder.mozilla.org/jobs?repo=try&revision=b195379dbeda6bcc31bd835f944679376dfd5c26

Jan, can you test this one once done?

Comment 33

[Darkspirit]

Thanks, confirmed, this patch works.
Tested with GLX and MOZ_X11_EGL.
KDE X11, Ubuntu 21.04, GTX 1060, Nvidia driver 470, FXAA manually enabled in Nvidia X Server settings.
good:
mozregression --repo try --launch b195379dbeda6bcc31bd835f944679376dfd5c26
mozregression --repo try --launch b195379dbeda6bcc31bd835f944679376dfd5c26 --pref gfx.x11-egl.force-disabled:true
bad:
mozregression --launch 2021-09-17

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3b0d7e251b85
Force-disable Nvidia FXAA, r=aosmond

Comment 35

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/3b0d7e251b85

Comment 36

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

The patch landed in nightly and beta is affected.
:rmader, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 37

[Robert Mader [:rmader]]

For the record, the NV driver 470.74 also blocklist FXAA for Firefox now: https://www.nvidia.com/download/driverResults.aspx/180483/en - but that probably does not affect Thunderbird and FF rebrands.

Comment 38

[Darkspirit]

You could try to request uplifts for beta 93 and esr 91 (91.2 = 2021-10-05). Duplicate bugs indicate a demand for footgun prevention.

Comment 39

[Robert Mader [:rmader]]

Comment on attachment 9241815 [details]
Bug 1714483 - Force-disable Nvidia FXAA, r=aosmond

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The issue affects Thunderbird and other ESR products.
• User impact if declined: Some Nvidia users (with a relatively popular driver setting enabled) will see the GUI rendered unusable in affected products.
• Fix Landed on Version: 94
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The code only sets an environment variable (trivial in code complexity), which again is only used by the driver in question as a workaround for exactly the issue we want to fix here. It is pretty much guaranteed that there are no side effects.
• String or UUID changes made by this patch:

Beta/Release Uplift Approval Request

• User impact if declined: Some Nvidia users (with a relatively popular driver setting enabled) will see the GUI rendered unusable in affected products.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The code only sets an environment variable (trivial in code complexity), which again is only used by the driver in question as a workaround for exactly the issue we want to fix here. It is pretty much guaranteed that there are no side effects.
• String changes made/needed:

Comment 40

[Pascal Chevrel:pascalc]

Comment on attachment 9241815 [details]
Bug 1714483 - Force-disable Nvidia FXAA, r=aosmond

The number of duplicates indicates that this is a serious bug making Firefox barely usable for some of our users , let's take this into 93 beta 8, thanks.

Comment 41

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/5b34a770fb88

Comment 43

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9241815 [details]
Bug 1714483 - Force-disable Nvidia FXAA, r=aosmond

Approved for 91.2esr.

Comment 44

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/0e3f13dc2d09

Comment 45

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Was able to reproduce the issue on a Thinkpad T430 with NVS 5400M (Proprietary 390.144 driver) with FXAA forced in Nvidia X Server settings on Firefox 89.0.2 under Ubuntu 20.04.

The issue is no longer reproducing on Firefox 93.0b9 and 91.2.0ESR on the same system.