Closed Bug 1663273 Opened 4 years ago Closed 4 years ago

Top half of the browser has a solid color when using WebRender/GLX/KDE without compositing/X11/proprietary Nvidia (does not occur with MOZ_GTK_TITLEBAR_DECORATION=system or none or MOZ_X11_EGL=1)

Categories

(Core :: Widget: Gtk, defect, P2)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 82
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox80 --- unaffected
firefox81 --- unaffected
firefox82 --- disabled
firefox83 --- disabled
firefox84 --- disabled
firefox85 --- fixed

People

(Reporter: burningjule, Assigned: rmader)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: correctness, nightly-community, regression)

Attachments

(4 files)

Capture d’écran_2020-09-05_20-05-19.png
253.22 KB, image/png
Details
2020-10-07_11-54-36.mp4
1.59 MB, video/mp4
Details
widget.log
10.90 KB, text/plain
Details
Bug 1663273 - Update shape mask setup, r?rmader
47 bytes, text/x-phabricator-request
Details | Review

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

Steps to reproduce:

A white band on the top of each web page (see screenshot) since yesterday afternoon 4.9.2020
On Twitter just no time line
I've wait updates: nothing have change
I've download a new Nightly: nothing have change
In these conditions impossible with my knowledge to try anything locally

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

Component: Untriaged → Graphics
Product: Firefox → Core

Thanks for the report! Can you disable all your addons to verify that they don't cause the problem?
Could you try to find a regression range?
$ pip3 install --upgrade mozregression
$ mozregression --good 2020-09-01 --bad 2020-09-04
You can also launch dates directly:
$ mozregression --launch 2020-09-04 --pref gfx.webrender.all:true
If you can't reproduce this bug with these commands, you might have set specific prefs that caused this. Please try to find out which ones.
Please also open about:support, click on "copy text to clipboard" and paste it here. Thanks!

Keywords: correctness
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Correction: Firefox 82.0a1 concerned. Firefox 80 I am with now is ok.
Impossible to do anything with addons: white band still on the top of the page
Impossible to do anything with about:support: the same
also with about:config
Under Linux I use
firefox -p <session>
Each sessions I open with Nightly show this bug. Even the "defaut" session without any addons

Ok. Bug come to me with "2020-09-04-09-43-41" version. 2020-09-03-15-18-16 seems ok, no white band hiding top of the page.
https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2020/09/
I tried to reproduce on another machine under Xubuntu 20.04 too: no problem with 2020-09-04-09-43-41. Other machine is a total office one. But even is there a crash report. I've send: 21h48 in Grennwitch. IP 81.56.158.74. Country: France
Mine personal machine, where the bug is, is a Ryzen 7 processor on Gigabytes motherboard and Nvidia 1050 ti, under Xubuntu 20.04.

Summary: White band → Rendering issue: White band on the top of the page
Summary: Rendering issue: White band on the top of the page → Rendering issue on linux: White band on the top of the page

Thanks! Then it's probably the same as bug 1663317.

status-firefox80: --- → unaffected
status-firefox81: --- → unaffected
status-firefox82: --- → affected
status-firefox-esr68: --- → unaffected
status-firefox-esr78: --- → unaffected
Component: Graphics → Widget: Gtk
Keywords: nightly-community, regression
Regressed by: 1460959
Has Regression Range: --- → yes
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

Solved confirmed by last update.
Thanks all :)

Is the titlebar hidden by default for you after the update?
Thanks.

Flags: needinfo?(burningjule)

Martin Stránský: No !
Only the WebPage high contain part

Status: RESOLVED → VERIFIED
Flags: needinfo?(burningjule)

Hmm, this is said to be fixed but I see the same on a Nightly from today (2020-09-09) on current KDE (openSUSE Tumbleweed, so current-release software all around) with NVidia graphics and up-to-date proprietary drivers, with titlebar disabled by default (but if I switch it on, I see the same white band on websites), using WebRender compositing according to about:support.

When I reset the manually enabled gfx.webrender.enabled and restart Firefox, I get Basic compositing according to about:support and the white band is gone.

(In reply to Robert Kaiser from comment #11)

When I reset the manually enabled gfx.webrender.enabled and restart Firefox, I get Basic compositing according to about:support and the white band is gone.

So you see the white area with latest KDE + WebRender only, right?

Flags: needinfo?(kairo)

(In reply to Martin Stránský [:stransky] from comment #12)

So you see the white area with latest KDE + WebRender only, right?

With latest KDE, and I see the white area in Website content only with Webrender, not with Basic, yes. Also, only very recent Nightly (saw it today for the first time, but could potentially be that yesterday I used a 1-2 day old Nightly, but probably not older than that, and it did not have the white stripe/area even with Webrender).
Another note is that it is visible in the web content area only, not in chrome, which is always fine, and a GitHub page had its header bar visible and the white area only in the scrollable area below it, so it may be that it's actually scroll containers that have that white area on top.

Flags: needinfo?(kairo)

OK, did some more testing with WebRender on, it's not scroll containers but some websites can end up rendering some stuff over that blank box, I guess it's things that get rendered into other (high) layers somewhere in layout. Interestingly, the HTML structure in devtools inspector remains empty as well if it's at the bottom and higher than a few lines and shorter than the border of the empty area on the web page, it's empty space is the dark background color of the theme, so it seems not to be a "white" area but a "solid-background-colored" area instead. Also, when inspector is open, I don't see the website rendered at all but the highlight boxes for elements do render. And resizing the window is causing flickering on its whole area (chrome plus content) a lot.

See Also: → 1663809
Status: VERIFIED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Assignee: nobody → stransky
Status: REOPENED → ASSIGNED
Priority: -- → P2
Summary: Rendering issue on linux: White band on the top of the page → [KDE] Rendering issue on linux: White band on the top of the page

Thanks, I'll look at it.

As per bug 1460959: my symptoms are no titlebar (expected) and no window borders making windows non-resizable (except popup windows like Help/About Nightly) on Debian stable with KDE. Switching gfx.webrender.enabled off and on does not make any difference. I don't get the white band described here, inside the windows everything seems to work normally, no rendering issues. WebGL 1 Driver Renderer: X.Org -- AMD ARUBA (DRM 2.50.0 / 5.7.0-0.bpo.2-amd64, LLVM 7.0.1), WebGL 1 Driver Version: 3.1 Mesa 18.3.6

FWIW, the bug here happens independent of the titlebar setting and has nothing to do with window borders, so Arthur, what you are seeing is a different bug.

I now have my other machine with Intel graphics updated to the same KDE/Plasma and Nightly versions and I don't see the white band there even with WebRender, so it seems to be an NVidia+WebRender issue (at least with proprietary NVidia gfx drivers, switching to nouveau is pretty hard so I can't test that right now).

Summary: [KDE] Rendering issue on linux: White band on the top of the page → [KDE] Rendering issue on linux: White band on the top of the web page content with Nvidia graphics and WebRender
Blocks: gfx-83

Hey Andrew, can you take a look? Something we might want to track. I'm not sure if this is in the right component, we might want to move it over to Graphics.

Flags: needinfo?(aosmond)
See Also: → 1656857

I can confirm the issue with Developer Edition and Nightly on the same machine and I had to disable webrender to get everything back fine.

See Also: 1656857 →

bug 1656857 comment 13: Disabling gfx.webrender.picture-caching seems to circumvent this bug on KDE (bug 1518796 was already known on KDE, I assumed it was connected to CSD regression bug 1502519. bug 1656211 seem related. = From my view they are all the same.)
bug 1656857 comment 10: Apparently this doesn't occur with MOZ_X11_EGL=1 on KDE/X11/proprietary Nvidia.

I can help with testing if you need, I am already a Firefox NIghtly daily user. I am on Debian sid with KDE 4.19 (I will update today to 5.20) and Nvidia proprietary drivers.

Giving backs as this is not a Gtk issue but rather a webrender one.

Assignee: stransky → nobody
Status: ASSIGNED → NEW
Component: Widget: Gtk → Graphics: WebRender
Attached video 2020-10-07_11-54-36.mp4 —

KDE X11, Debian Testing, Nvidia GTX1060, proprietary driver 450.66
After disabling compositing I can now 100% reliably reproduce this. This is like bug 1518796 comment 11 (and therefore related to bug 1502519 comment 3), but more extreme.

  1. Disable compositing: KDE System Settings > Display > Compositor > uncheck "Enable on Start". Logout, login.

  2. Reproducible with:
    mozregression --launch 20201006161706 --pref gfx.webrender.all:true -a about:support

  3. Not reproducible with:
    MOZ_GTK_TITLEBAR_DECORATION=none mozregression --launch 20201006161706 --pref gfx.webrender.all:true -a about:support
    MOZ_GTK_TITLEBAR_DECORATION=system mozregression --launch 20201006161706 --pref gfx.webrender.all:true -a about:support
    MOZ_X11_EGL=1 mozregression --launch 20201006161706 --pref gfx.webrender.all:true -a about:support

  4. Is XShape usage the root cause? (Or something in this direction?)

Only occuring on X11 and can be fixed by disabling CSD.

status-firefox83: --- → disabled
Component: Graphics: WebRender → Widget: Gtk

(Nicolas Frandeboeuf from bug 1656857 comment 14)

Here it is: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=aa032cbc94551a0f6e7e821d78aa0388f998e830&tochange=bb0078598fc8d05033d58cd7c8963ec14a5b3925

The regression range is correct. Is does not occur with last good:
MOZ_GTK_TITLEBAR_DECORATION=client mozregression --repo autoland --launch aa032cbc94551a0f6e7e821d78aa0388f998e830 --pref gfx.webrender.all:true -a about:support
MOZ_GTK_TITLEBAR_DECORATION=system mozregression --repo autoland --launch aa032cbc94551a0f6e7e821d78aa0388f998e830 --pref gfx.webrender.all:true -a about:support
MOZ_GTK_TITLEBAR_DECORATION=none mozregression --repo autoland --launch aa032cbc94551a0f6e7e821d78aa0388f998e830 --pref gfx.webrender.all:true -a about:support

Not reproducible on Mesa/Nouveau.

Blocks: wr-nv-linux
Summary: [KDE] Rendering issue on linux: White band on the top of the web page content with Nvidia graphics and WebRender → Top half of the browser has a solid color when using WebRender/GLX/KDE without compositing/X11/proprietary Nvidia (does not occur with MOZ_GTK_TITLEBAR_DECORATION=system or none)
Summary: Top half of the browser has a solid color when using WebRender/GLX/KDE without compositing/X11/proprietary Nvidia (does not occur with MOZ_GTK_TITLEBAR_DECORATION=system or none) → Top half of the browser has a solid color when using WebRender/GLX/KDE without compositing/X11/proprietary Nvidia (does not occur with MOZ_GTK_TITLEBAR_DECORATION=system or none or MOT_X11_EGL=1)
Summary: Top half of the browser has a solid color when using WebRender/GLX/KDE without compositing/X11/proprietary Nvidia (does not occur with MOZ_GTK_TITLEBAR_DECORATION=system or none or MOT_X11_EGL=1) → Top half of the browser has a solid color when using WebRender/GLX/KDE without compositing/X11/proprietary Nvidia (does not occur with MOZ_GTK_TITLEBAR_DECORATION=system or none or MOZ_X11_EGL=1)

Martin, do you know if there's a strong reason we use client for MOZ_GTK_TITLEBAR_DECORATION on KDE? (https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#7775)

Could we use the same setting as on Gnome?

Flags: needinfo?(stransky)

So, MOZ_GTK_TITLEBAR_DECORATION is different from the "titlebar" setting in customize? As I mentioned, the setting of that titlebar setting makes no difference, I see the bug with both.

(In reply to Robert Kaiser from comment #29)

So, MOZ_GTK_TITLEBAR_DECORATION is different from the "titlebar" setting in customize? As I mentioned, the setting of that titlebar setting makes no difference, I see the bug with both.

Yep, it's not the same.

FTR, I guess we should not enable Webrender on a non-composited desktops by default. There will likely be a couple of issues, e.g. possible tearing, see bug 1667116

Tearing anyway occurs with Basic (bug 1420712 comment 4).
With WebRender, one might still have tearing in some edge cases, but with performance.

(In reply to Darkspirit, Servo QA from comment #31)

Tearing anyway occurs with Basic (bug 1420712 comment 4).
With WebRender, one might still have tearing in some edge cases, but with performance.

Oh, fair point. And we might be able to fix it with better vsync.

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

Martin, do you know if there's a strong reason we use client for MOZ_GTK_TITLEBAR_DECORATION on KDE? (https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#7775)

Could we use the same setting as on Gnome?

First let me explain what's the difference here.

On Gnome we use MOZ_GTK_TITLEBAR_DECORATION=system. That means:

  • we use only one GdkWindow to draw all firefox content, the gdk window is owned by mShell
  • mContainer (a child window of mShell which handles all events) does not have it's own GdkWindow, uses the mShell one.
  • system titlebar is removed from Firefox toplevel window by gdk_window_set_decorations() call. We use eBorderStyle_border style which means we ask window manager to keep only border of the GdkWindow and remove the titlebar.
  • we get toplevel window extents (border sizes) from _NET_FRAME_EXTENTS at nsWindow::UpdateClientOffsetFromFrameExtents() from "property-notify-event" handler.

Unfortunately some window managers (kwin for instance) does not honor the gdk_window_set_decorations(eBorderStyle_border) style and does not remove the titlebar from firefox main window. In this case we use a trick with CSD and we call it MOZ_GTK_TITLEBAR_DECORATION=client:

  • mShell is a toplevel window and has it's own GdkWindow and uses client side decorations. mContainer is a child of mShell and also has it's own GdkWindow.
  • We use gtk_window_set_titlebar(GTK_WINDOW(mShell), gtk_fixed_new()) to set a GtkFixed as custom (empty) titlebar to the toplevel window. The GtkFixed should have a zero size so it looks like there isn't any titlebar, but mShell contains two widgets - GtkFixed and mContainer.
  • We draw Firefox content to GdkWindow owned by mContainer.
  • we get toplevel window extents (border sizes) from nsWindow::UpdateClientOffsetFromCSDWindow() which is called on nsWindow::OnSizeAllocate() / nsWindow::OnScaleChanged(). We get the border size as a difference of origins of mShell GdkWindow and mContainer GdkWindow.

I have a suspicion that this condition may be wrong:
https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/widget/gtk/nsWindow.cpp#4040
and we should update the extents in CSD (client mode) even when system titlebar is turned on.

Flags: needinfo?(stransky)

Jan, can you please try to run firefox as:

MOZ_LOG="Widget:5" ./firefox

and attach the log here? It should be helpful is the session is as short as possible, i.e. just open firefox with the white band shown and close it.
Thanks.

Flags: needinfo?(jan)
Attached file widget.log —

My desktop is 2560x1440, no scaling. I waited until the window opened, saw the bug, pressed Ctrl+Q.
It's grey, I have a dark theme. (Screencast in comment 24: left window was mozregression.)

MOZ_LOG="Widget:5" mozregression --launch 20201007094223 --pref gfx.webrender.all:true -a about:support -P stdout > widget.log

Flags: needinfo?(jan)
Attachment #9180244 - Attachment mime type: text/x-log → text/plain

Thanks for the log. I don't see anything wrong there, looks like the widget has a correct size.

Jan, can you confirm that KDE compositing setting makes the difference here? i.e. with KDE screen compositing enabled the bug does not appear?
Thanks.

Flags: needinfo?(jan)

We may need to use apitrace/renderdoc to check how the backbuffer/textures look like.

(In reply to Martin Stránský [:stransky] from comment #37)

Jan, can you confirm that KDE compositing setting makes the difference here? i.e. with KDE screen compositing enabled the bug does not appear?
Thanks.

Correct. The bug only occurs as long as compositing is disabled. Changing settings of enabled compositing doesn't help [to make this bug occur}. Only disabling compositing helps [to make this bug occur]. I need to logout and login to Plasma to apply changes.
Nvidia X Server Settings: Forcing "Full Composition Pipeline", disabling "Sync to VBlank", disabling "Allow flipping", disabling "Use Confirmant Texture Clamping" do not help.

Flags: needinfo?(jan)

(In reply to Darkspirit from comment #39)

Correct. The bug only occurs as long as compositing is enabled.

Jan, in comment 24 you wrote it's reproducible when it's disabled - was enabled a typo? ;)

Disable compositing: KDE System Settings > Display > Compositor > uncheck "Enable on Start". Logout, login.

Omg. My brain is defect.
KDE Compositing on == boring, no bugs visible.
KDE Compositing off == bug.

I just checked myself as well as I thought I would surely have KDE compositing enabled, and I found it was automatically disabled because it detected a crash in the past. Enabling it again made the bug disappear even with WebRender on, so I can confirm what Darkspirit is saying.

I can confirm too, I had compositing disabled for a crash in the past (that I don't remember) so reenabling fixed the issue.

KDE X11 without compositing, Debian Testing, Nvidia GTX 1060, proprietary driver 450.66
I could narrow it down, but I can't explain it!
If I manually set sTransparentMainWindow to true, the bug does not occur.
The following check prevents it from ever becoming true because I'm on non-composited KDE: https://searchfox.org/mozilla-central/rev/919607a3610222099fbfb0113c98b77888ebcbfb/widget/gtk/nsWindow.cpp#4165,4178
If I remove the check, the bug only occurs if I manually create mozilla.widget.use-argb-visuals=false on about:config.

Gnome X11, Debian Testing, Nvidia GTX 1060, proprietary driver 450.66
With GTK_CSD=1 I can reproduce this bug even on Gnome X11. mozilla.widget.use-argb-visuals=false/true can't fix it on Gnome X11.

bug:
GTK_CSD=1 mozregression --launch 20201008094950 --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 mozregression --launch 20201008094950 --pref gfx.webrender.all:true mozilla.widget.use-argb-visuals:false -a about:support
GTK_CSD=1 mozregression --launch 20201008094950 --pref gfx.webrender.all:true mozilla.widget.use-argb-visuals:true -a about:support

KDE X11 with compositing disabled: comment 24 + comment 26

Gnome X11, Debian Testing, Nvidia GTX 1060, proprietary driver 450.66
When using GTK_CSD=1 on Gnome X11, this bug is reproducible even long before the change that regressed KDE.
Trying to gather some history on GTK_CSD=1 Gnome X11:

The bug is even reproducible with EGL:
MOZ_X11_EGL=1 GTK_CSD=1 mozregression --launch 20201008094950 --pref gfx.webrender.all:true -a about:support

Going back step by step:
GTK_CSD=1 mozregression --repo autoland --launch aa032cbc94551a0f6e7e821d78aa0388f998e830 --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 mozregression --launch 2020-06-01 --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 mozregression --launch 2020-02-01 --pref gfx.webrender.all:true -a about:support
Fine:
GTK_CSD=1 mozregression --launch 2019-08-01 --pref gfx.webrender.all:true -a about:support

Apparently there was a time when picture caching only worked for web content, but not about:support:
GTK_CSD=1 mozregression --good 2019-08-01 --bad 2020-02-01 --pref gfx.webrender.all:true -a about:support

4:43.76 INFO: Last good revision: 75a7a3400888018a5f9b09c624dd22308f166807 (2019-11-04)
4:43.76 INFO: First bad revision: 4d585c7edc7683e4b35eca6b18c9a646a1b8a78d (2019-11-05)
4:43.76 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=75a7a3400888018a5f9b09c624dd22308f166807&tochange=4d585c7edc7683e4b35eca6b18c9a646a1b8a78d
4:46.98 INFO: There are no build artifacts for these changesets (they are probably too old).

probably:

23882236aac3275d2b4bfcda939866c5f64b5478 Glenn Watson — Bug 1591580 - Support picture caching for parent process content. r=kvark

Then let's test with web content:

Entirely solid grey tab content:
GTK_CSD=1 mozregression --launch 2019-08-01 --pref gfx.webrender.all:true -a https://www.mozilla.org/en-US/

Wildly flickering tiles, they switch between their content and white:
GTK_CSD=1 mozregression --launch 2019-02-01 --pref gfx.webrender.all:true -a https://www.mozilla.org/en-US/

The website's background color is my theme color (grey): Corruption or depth problem?
GTK_CSD=1 mozregression --launch 2018-11-01 --pref gfx.webrender.all:true -a https://www.mozilla.org/en-US/

Visually fine, but "Compositing OpenGL" because of "(#0) Error Failed GL context creation for WebRender: 0":
GTK_CSD=1 mozregression --launch 2018-06-01 --pref gfx.webrender.all:true -a https://www.mozilla.org/en-US/ -a about:support

Btw. If we don't set the env var on the same build, WebRender works without problem and does not fall back to OpenGL:
mozregression --launch 2018-06-01 --pref gfx.webrender.all:true -a https://www.mozilla.org/en-US/

bad: Visually fine, but "Compositing: OpenGL" because of "(#0) Error Failed GL context creation for WebRender: 0".
good: WebRender: The website's background color is my theme color (grey): Corruption or depth problem?
GTK_CSD=1 mozregression --find-fix --bad 2018-06-01 --good 2018-11-01 --pref gfx.webrender.all:true -a https://www.mozilla.org/en-US/ -a about:support

3:54.24 INFO: First good revision: d9e6ce390607ad8c227adc2ad2ff3cac89a814bc (2018-08-07)
3:54.24 INFO: Last bad revision: 588a314db0d5d2f7d1b758d09f170e3afb1283a3 (2018-08-06)
3:54.25 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=588a314db0d5d2f7d1b758d09f170e3afb1283a3&tochange=d9e6ce390607ad8c227adc2ad2ff3cac89a814bc

probably:

d745e4118de757288c9d99934e6906de9b6a0ff6 sotaro — Bug 1479181 part 2 - Remove glXChooseVisual() usage r=jgilbert
e6764dc173956fa095d06dad0ba8961e004d5319 sotaro — Bug 1479181 part 1 - Expose glxGetConfig() in GLXLibrary r=jgilbert

On KDE without compositing/proprietary Nvidia, the following options fix the WebRender problem:

  • Setting transparent main window: comment 45 (should this be done as immediate fix?)
  • Disabling picture caching (to prevent the bug from being cached?)
  • using EGL: MOZ_X11_EGL=1 mozregression --launch 20201008094950 --pref gfx.webrender.all:true -a about:support

vs.
On Gnome X11, this bug is reproducible with GLX and EGL as long as GTK_CSD=1 is set.
GTK_CSD=1 mozregression --launch 20201008094950 --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --launch 20201008094950 --pref gfx.webrender.all:true -a about:support

With build from bug 1669275 comment 10 we can test the new GLContextEGL::FindVisual which would only be used on proprietary Nvidia:

Gnome X11 without GTK_CSD=1 is still fine:
mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support
MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support

Gnome X11 with GTK_CSD + GLX: This bug is still reproducible:
GTK_CSD=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support

Gnome X11 with GTK_CSD + EGL: Glitches + fallback to OpenGL (new regression):
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support

Compositing OpenGL
(#0) Error Failed to create EGLSurface!: 0x3009
(#1) Error Failed to create EGLSurface!: 0x3009
(#2) Error Failed GL context creation for WebRender: 0
(#3) Error FEATURE_FAILTURE_WEBRENDER_INITIALIZE_UNSPECIFIED
(#4) Error Failed to connect WebRenderBridgeChild.

Build from bug 1669275 comment 10 (GLContextEGL::FindVisual for proprietary Nvidia) on KDE without compositing/proprietary Nvidia:

This bug (comment 24) is still present as the GLX path is unchanged:
mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support

EGL still circumvents this bug and is still fine (no regression):
MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support

On KDE with compositing/proprietary Nvidia:
Fine:
mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support
mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true mozilla.widget.use-argb-visuals:true -a about:support
MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support
MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true mozilla.widget.use-argb-visuals:false -a about:support
MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true mozilla.widget.use-argb-visuals:true -a about:support
GTK_CSD=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true -a about:support

Disabling mozilla.widget.use-argb-visuals makes this bug (comment 24) even reproducible on "KDE with compositing", but only when using GLX:
mozregression --repo autoland --launch d42dc1f995bb --pref gfx.webrender.all:true mozilla.widget.use-argb-visuals:false -a about:support

No longer blocks: gfx-83

So far this won't be fixed by bug 1656211 comment 28:

KDE without compositing/proprietary Nvidia:
mozregression --repo try --launch f99b095e7b7565c05290605d5d182e0d6060c4d3 --pref gfx.webrender.all:true -a about:support

Gnome X11/proprietary Nvidia:
GTK_CSD=1 mozregression --repo try --launch f99b095e7b7565c05290605d5d182e0d6060c4d3 --pref gfx.webrender.all:true -a about:support

I experienced the same problem today after an apt upgrade that updated Firefox to version 82.0, and nvidia proprietary drivers to version 450.80.02. I had been using webrender prior to this without any issues - worked around it by disabling webrender.

Using X11 / MATE / marco window manager with compositing disabled.

Is there something I could run to help narrow down the cause?

(In reply to Alex from comment #52)

Is there something I could run to help narrow down the cause?

Alex, could you check if the issue is fixed by running the EGL backend, i.e. by setting MOZ_X11_EGL=1?

Flags: needinfo?(alex)

Alex, could you check if the issue is fixed by running the EGL backend, i.e. by setting MOZ_X11_EGL=1?

Exporting that environment variable does fix this top solid-colour rectangle issue with webrender, although it introduces a separate graphical corruption issue when scrolling. (either by clicking & dragging the scrollbar, or using middle-click autoscroll):

https://i.abaines.me.uk/moz_egl.webm

It didn't seem to happen immediately - I had to open multiple tabs and switch between them before I noticed it.

Flags: needinfo?(alex)
  • Please open about:config, set gfx.webrender.max-partial-present-rects to 0, restart Firefox and check if that fixes the EGL bug. Thanks!
  • Does the same bug occur with https://nightly.mozilla.org ? Run MOZ_X11_EGL=1 path/to/firefox, open about:config, set gfx.webrender.all to true, restart Nightly and check if the bug occurs or not.

Having another look, I think what happens is:

According to bug 1675768 comment 24 this bug is fixed if we don't set needsAlphaVisual to false in the first case - so probably we it's enough to always make it true for WR as it should be. Will prepare a patch.

Assignee: nobody → robert.mader
Status: NEW → ASSIGNED

(In reply to Darkspirit from comment #55)

  • Please open about:config, set gfx.webrender.max-partial-present-rects to 0, restart Firefox and check if that fixes the EGL bug. Thanks!
  • Does the same bug occur with https://nightly.mozilla.org ? Run MOZ_X11_EGL=1 path/to/firefox, open about:config, set gfx.webrender.all to true, restart Nightly and check if the bug occurs or not.

gfx.webrender.max-partial-present-rects was already set to 0.

After restarting, the issue would not occur until I opened multiple tabs, and dragged the first tab to re-order it. At that point the following message was printed in the terminal:

[GFX1-]: Failed to create EGLSurface!: 0x3009
[GFX1-]: Failed to create EGLSurface!: 0x3009
[GFX1-]: Failed GL context creation for WebRender: 0
[GFX1-]: FEATURE_FAILTURE_WEBRENDER_INITIALIZE_UNSPECIFIED
[GFX1-]: Failed to connect WebRenderBridgeChild.
[GFX1-]: Compositors might be mixed (5,2)

And the corruption with scrolling could be reproduced as in the video.

Trying with Firefox Nightly 84.0a1 (2020-11-14) (64-bit):
Enabling only the webrender preference, without the MOZ_X11_EGL variable - the original problem (top half of the screen is a solid colour) occurs.

After exporting the variable the top-half problem is gone, but doing the same steps (re-ordering tab) causes the same scrolling corruption issue, with the same message printed.

I'm not sure if this should be moved to a separate bug?

Here's a try run with the above patch: https://treeherder.mozilla.org/jobs?repo=try&revision=b8c851cd09ab4e5693b7474724b0c3727f1a6263

Once it's finished, can you try with mozregression --repo try --launch b8c851cd09ab4e5693b7474724b0c3727f1a6263 --pref gfx.webrender.all:true? (with and without MOZ_X11_EGL=1)

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

Here's a try run with the above patch: https://treeherder.mozilla.org/jobs?repo=try&revision=b8c851cd09ab4e5693b7474724b0c3727f1a6263

Once it's finished, can you try with mozregression --repo try --launch b8c851cd09ab4e5693b7474724b0c3727f1a6263 --pref gfx.webrender.all:true? (with and without MOZ_X11_EGL=1)

Looking at that page, it seems like the build failed?

If I try the command anyway, I get:

 0:01.06 INFO: b8c851cd09ab4e5693b7474724b0c3727f1a6263 is not a release, assuming it's a hash...
 0:04.10 ERROR: Unable to find build info using the taskcluster route 'gecko.v2.try.shippable.revision.b8c851cd09ab4e5693b7474724b0c3727f1a6263.firefox.linux64-opt'

(In reply to Alex from comment #58)
Thanks for testing! Yes, please file a new bug for that Nightly/MOZ_X11_EGL/proprietary Nvidia scrolling corruption bug: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A+WebRender
Please also open about:support after reproducing the bug with Nightly, click on "Copy text to clipboard" and paste it into the attachment field.

See Also: → 1677314

Meh, sorry, here's a new one: https://treeherder.mozilla.org/jobs?repo=try&revision=3f87fab38efb2b5433a75f6d26f663e65305a17b

mozregression --repo try --launch 3f87fab38efb2b5433a75f6d26f663e65305a17b --pref gfx.webrender.all:true

Offtopic: I'm so much looking forward to remove all the alpha-less code paths sooner or later - AFAIK their benefit is mostly negligible these days and maybe even decremental in many cases, with RGB hitting slower paths than ARGB or XRGB.

KDE (compositing disabled), X11, Debian Testing, GTX1060, driver 450.80.02
This bug is still reproducible with current Nightly: mozregression --launch 20201114215126 --pref gfx.webrender.all:true
This bug is fixed by attached patch: mozregression --repo try --launch 3f87fab38efb2b5433a75f6d26f663e65305a17b --pref gfx.webrender.all:true
Thanks!

(Offtopic: If I mousedown on a windows' border as if I wanted to resize it, and press F11, its decoration is hidden and its content switches into fullscreen state - at the place of the window. Can be reproduced with Firefox, gedit, VLC. KDE bug or feature? ^^)

This bug would still be reproducible when using GTK_CSD=1 on Gnome X11, but that shouldn't matter, I guess:
GTK_CSD=1 mozregression --repo try --launch 3f87fab38efb2b5433a75f6d26f663e65305a17b --pref gfx.webrender.all:true

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

Meh, sorry, here's a new one: https://treeherder.mozilla.org/jobs?repo=try&revision=3f87fab38efb2b5433a75f6d26f663e65305a17b

mozregression --repo try --launch 3f87fab38efb2b5433a75f6d26f663e65305a17b --pref gfx.webrender.all:true

Yeah this seems to fix the solid colour problem for me.

Doesn't affect https://bugzilla.mozilla.org/show_bug.cgi?id=1677314 (glitches still reproducible)

Hi Robert,

thanks for the patch. I need to think a bit about it as it may come with possible regressions. Some thoughts:

  • https://gitlab.gnome.org/GNOME/gtk/-/issues/3105 claims rgba visual does no works well on non-compositing screens and Gtk does not use it (if I read that correctly).
  • How webrender/rgba works on non-compositing screens?
  • is RGBA visual really needed for webrender?
  • this is about popups - do we enable wenrender for popups? I think there was a change there recently.
  • can we for disable webrender for popups and use basic compositor with shape masks instead?

Some notes from Matrix:

robert.mader: lsalzman: the question would be if https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#4368-4372 is really needed
lsalzman: robert.mader: no depth buffer is required if SWGL is used at least
gw: robert.mader: I think that comment / code is redundant now
(the alpha visual requirement)
lsalzman: robert.mader: not sure what the readback requirement is about, because SWGL will render things the same ultimately regardless... so the only reason to use alpha would be because the widget code needs it
robert.mader: and for WR?
like hardware WR :)
lsalzman: gw: we don't require a depth buffer for the simple compositor in WR to operate, right? the picture cache tiles are the only thing that need depth?
gw: lsalzman: We do make use of it, to z-reject tiles - but it can be made to run without depth on the main visual fairly easily, if desired
gw: robert.mader: https://bugzilla.mozilla.org/show_bug.cgi?id=1524168 is the bug that added the alpha visual - we could try removing it and see if that test works now? :)
lsalzman: gw: well, don't we mostly composite in order anyway?
gw: robert.mader: (I suspect that requirement might have been from when WR picture caching did readbacks from the main target, which it no longer does)
robert.mader: gw: ah that's really good to know
gw: lsalzman: We do a normal opaque tiles followed by alpha tiles. But we could just composite in order if no depth is available

(In reply to Martin Stránský [:stransky] from comment #67)

Hi Robert,

thanks for the patch. I need to think a bit about it as it may come with possible regressions. Some thoughts:

Hm, IIUC it simply wouldn't do much.

  • is RGBA visual really needed for webrender?

According to the chat above maybe not

  • this is about popups - do we enable wenrender for popups? I think there was a change there recently.

I think so, yes, see bug 1479135 (or is that about something else?).

  • can we for disable webrender for popups and use basic compositor with shape masks instead?

IIUC the basic compositor is going away sooner or later, with SWGL being developed to be able to run WR in software. So I assume we really should try to make things work with WR.

Thanks Robert, I'm going to look at it.

I guess main focus is KDE with compositing disabled, right?

(In reply to Martin Stránský [:stransky] from comment #70)

I guess main focus is KDE with compositing disabled, right?

I think so, but might be worth checking Mate or XFCE, too, given they are also quite popular.

Thanks Robert. I did some experiments mainly with the NVIDIA closed source drivers and also EGL drivers and think the X11 alpha/non-alpha visual does mean much in this case. Bug 1663003 / https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376 is related here. The GL rendering pipeline uses its own setup and the final presentation to X11 is another thing.

The setup at nsWindow::Create() has two purposes:

So we really can always use alpha visual for Gtk widgets with WebRender and in case of non-compositing DE the alpha is ignored, as well as when we fails to match X11/EGL visuals. The IsAccelerated condition was here for old GL compositor, I thin we can drop it now and use WR only. Another question is how WR-SW is handled here.

Attachment #9187839 - Attachment description: Bug 1663273 - Always use argb-visuals with WR, r?stransky → Bug 1663273 - Update shape mask setup, r?stransky

So as the patch stands now it should enable shape masks again for menus on WR - that should fix bug 1479135

I could test before we accidentally break something. Could you make a linux64-opt try build?

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

That would be great, thanks! https://treeherder.mozilla.org/jobs?repo=try&revision=e4c8fa817145931390bf69bc39d36018bbac02b9

0 fixes, 3 regressions:

Intel HD Graphics 630 (KBL GT2), Mesa 20.2.2, Debian Testing

Basic GLX WR GLX SWWR GLX Basic EGL WR EGL SWWR EGL
Gnome Wayland x x x fine fine fine
Gnome Xwayland fine bug 1678804 but transparent top-left quarter bug 1674473 fine bug 1677892 bug 1674473
Gnome X11 fine fine bug 1674473 fine fine bug 1674473
KDE X11 without compositing fine bug 1479135 still present bug 1479135 even here fine bug 1479135 still present bug 1479135 even here
KDE X11 with compositing fine fine bug 1674473 fine fine bug 1674473

Proprietary Nvidia, GTX1060, Debian Testing

Basic GLX WR GLX SWWR GLX Basic EGL WR EGL SWWR EGL
Gnome X11 fine fine bug 1674473 fine fine bug 1674473
KDE X11 with compositing fine new: this bug also occurs here now bug 1674473 fine fine bug 1674473
KDE X11 without compositing fine this bug is still present bug 1479135 even here + new: if you close toolbar panels, artifacts of them remain (does not occur with 2020-11-21) fine bug 1479135 bug 1479135 even here + new: if you close toolbar panels, artifacts of them remain (does not occur with 2020-11-21)

Gnome Wayland
MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.force-disabled:true
MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.all:true
MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.all:true gfx.webrender.software:true

Gnome Xwayland
Gnome X11
KDE X11 without compositing
KDE X11 with compositing
mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.force-disabled:true
mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.all:true
mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.all:true gfx.webrender.software:true
MOZ_X11_EGL=1 mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.force-disabled:true
MOZ_X11_EGL=1 mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.all:true
MOZ_X11_EGL=1 mozregression --repo try --launch e4c8fa817145931390bf69bc39d36018bbac02b9 --pref gfx.webrender.all:true gfx.webrender.software:true

SWWR/KDE X11 without compositing/proprietary Nvidia
mozregression --launch 2020-11-21 --pref gfx.webrender.all:true gfx.webrender.software:true
MOZ_X11_EGL=1 mozregression --launch 2020-11-21 --pref gfx.webrender.all:true gfx.webrender.software:true

Oh my, yes makes sense. Brain fart by me, we now run set mTransparencyBitmapForTitlebar unconditionally and that doesn't work.

Martin, I'm dropping the ball on this again as I don't have a nvidia system to debug what's wrong with shape masks on it. Unfortunately it's a blocker for (SW)WR there.

But then again bug 1479135 is much more important as it also affects mesa drivers, will head over to that one.

Assignee: robert.mader → nobody
Status: ASSIGNED → NEW
Assignee: nobody → robert.mader
Status: NEW → ASSIGNED
Attachment #9187839 - Attachment description: Bug 1663273 - Update shape mask setup, r?stransky → Bug 1663273 - Update shape mask setup, r?rmader

(In reply to Martin Stránský [:stransky] from comment #78)

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=230f8c44f18b85947446ab2c9ba98dd17380b716

Jan, can you please try this build?
Thanks!

Flags: needinfo?(jan)

(In reply to Martin Stránský [:stransky] from comment #79)

(In reply to Martin Stránský [:stransky] from comment #78)

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=230f8c44f18b85947446ab2c9ba98dd17380b716

Jan, can you please try this build?
Thanks!

WebRender/GLX/GTK_CSD=1/Gnome X11/proprietary Nvidia still shows this bug (and with EGL it falls back to Basic).
WebRender/GLX/KDE without compositing/proprietary Nvidia is fixed.

Intel HD Graphics 630 (KBL GT2), Mesa 20.2.2, Debian Testing

Basic GLX WR GLX SWWR GLX Basic EGL WR EGL SWWR EGL
Gnome Wayland x x x fine fine found bug 1679215
Gnome Xwayland fine bug 1678804 but transparent top-left quarter bug 1674473 fine bug 1677892 bug 1674473
Gnome X11 fine fine bug 1674473 fine fine bug 1674473
Gnome X11 with GTK_CSD=1 fine fine bug 1674473 fine fine bug 1674473
KDE X11 without compositing fine bug 1479135 bug 1479135 fine bug 1479135 bug 1479135
KDE X11 with compositing fine fine bug 1674473 fine fine bug 1674473

Proprietary Nvidia, GTX1060, Debian Testing

Basic GLX WR GLX SWWR GLX Basic EGL WR EGL SWWR EGL
Gnome X11 fine fine bug 1674473 fine fine bug 1674473
Gnome X11 with GTK_CSD=1 fine this bug is still present bug 1674473 fine fallback, see below bug 1674473
KDE X11 with compositing fine fine bug 1674473 fine fine bug 1674473
KDE X11 without compositing fine this bug is fixed; bug 1479135 bug 1479135 fine bug 1479135 bug 1479135

MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.force-disabled:true -a about:support
MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true -a about:support
MOZ_ENABLE_WAYLAND=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true gfx.webrender.software:true -a about:support

mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.force-disabled:true -a about:support
mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true -a about:support
mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true gfx.webrender.software:true -a about:support
MOZ_X11_EGL=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.force-disabled:true -a about:support
MOZ_X11_EGL=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true -a about:support
MOZ_X11_EGL=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true gfx.webrender.software:true -a about:support

GTK_CSD=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.force-disabled:true -a about:support
GTK_CSD=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true gfx.webrender.software:true -a about:support
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.force-disabled:true -a about:support
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true -a about:support
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true gfx.webrender.software:true -a about:support

Gnome X11 with GTK_CSD=1 and MOZ_X11_EGL=1 on proprietary Nvidia:
Almost the same as in comment 48, but WebRender now falls back to Basic instead of OpenGL (bug 1677825):
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo try --launch 230f8c44f18b85947446ab2c9ba98dd17380b716 --pref gfx.webrender.all:true -a about:support

Compositing Basic
(#0) Error Failed to create EGLSurface!: 0x3009
(#1) Error Failed to create EGLSurface!: 0x3009
(#2) Error Failed GL context creation for WebRender: 0
(#3) Error FEATURE_FAILTURE_WEBRENDER_INITIALIZE_UNSPECIFIED
(#4) Error Failed to connect WebRenderBridgeChild.

In comparison, last good felt back to OpenGL, had window shadow glitches, didn't reliably update all tiles when scrolling:
GTK_CSD=1 MOZ_X11_EGL=1 mozregression --repo autoland --launch aa032cbc94551a0f6e7e821d78aa0388f998e830 --pref gfx.webrender.all:true -a about:support

Compositing OpenGL
(#0) Error Failed to create EGLConfig for WebRender with depth!
(#1) Error Failed to create EGLConfig for WebRender with depth!
(#2) Error Failed GL context creation for WebRender: 0
(#3) Error Failed to connect WebRenderBridgeChild.

Flags: needinfo?(jan)

Thanks, I thin we can check it in to improve the situation. Will look at the rest.

Pushed by btara@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/78ef1dbccb7a Update shape mask setup, r=rmader
Status: ASSIGNED → RESOLVED
Closed: 4 years ago → 4 years ago
status-firefox84: --- → disabled
status-firefox85: --- → fixed
Flags: needinfo?(aosmond)
Keywords: leave-open
Resolution: --- → FIXED
See Also: → 1683341

I can confirm that on KDE now webrender works without issues

v87, Gentoo, proprietary nvidia, X11, 30 bpp colour depth, compositor enabled in KDE, large dual screens (4K + 5K).

If this was ever fixed, looks like it has regressed in v87 (or a new bug with KDE compositing enabled? Or perhaps bug 1683341 is not Gnome specific?).

With webrender disabled - extremely sluggish, no artefacts.
With webrender enabled - fast, but with white band at the top of every page, including about: pages, even hides the window scrollbar behind it.

GTK_CSD and MOZ_GTK_TITLEBAR_DECORATION don't seem to make any difference.
MOZ_X11_EGL=1 fixes white band, but is sluggish, with console errors:

failed to load driver: nouveau
GFX1-]: Fallback (SW-)WR to Basic

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

Attachment

General

Creator:
Created:
Updated:
Size: