1719003 - KDE+XFCE+MATE/Nvidia: WebRender Firefox (manually enabled browser.tabs.drawInTitlebar on non-Gnome) and other applications get a large black border when composition gets disabled, e.g. by launching full screen games

Status: RESOLVED INVALID

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

Description

[Pulse]

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

Steps to reproduce:

1. Open instance of firefox, either Release or Nightly with a new profile.
2. Switch to a new workspace and launch Minecraft
3. Switch Minecraft to full screen
4. Switch back to Firefox workspace and observe large black border
5. Change Minecraft to Windowed, check Firefox. No Black border.
6. Force disable webrender in firefox (gfx.webrender.force-disabled to True) restart browser.
7. Switch Minecraft to full screen, check Firefox, no border.

normal

border

about:support

Minecraft 1.16.5 / Java 1.8.0_291

openSUSE Tumbleweed
Nvidia 460.84
Firefox 89.0.2 - openSUSE Mozilla Repo / Nightly 91.0a1 - Mozilla tarball

Actual results:

As above

Expected results:

In addition to the large black border the web page being displayed in Firefox is temporarily blanked out.

Comment 1

[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 revert this change in case you think the bot is wrong.

Comment 2

[Pulse]

Should have mentioned I'm using KDE 5.22.2

Comment 3

[Brad Werth [:bradwerth]]

Robert, is there something we might be doing in WebRender setup that affects how the window drop shadow is drawn by the compositor?

Comment 4

[Robert Mader [:rmader]]

Unfortunately this is currently expected, especially on prop. nvidia drivers :(
Disabling compositing is a legacy feature (not present on any modern display server), requiring us to use the Xshape extension to realize borders - which again does not play very well with acceleration (Webrender) on nvidia. We currently try to handle at least popups somewhat well (bug 1479135) - I'm not sure if there's a realistic option to perfectly handle things for the main window. It may require to switch between SSD and CSD or so.
In any case, I think it would be much easier if KDE only suspended the compositor while a fullscreen application is actually focused (this is how Gnome handles things, avoiding such issues). Handling dynamic accelerated/non-accelerated is likely not very easy in Firefox, and I'm not sure if anyone is willing to put in the effort for this case atm. Note that GTK4 apps will likely have similar issues.

Comment 5

[Jim Mathies [:jimm]]

Hey Pulse, curious do you see the same issue in Chrome?

Comment 6

[Pulse]

(In reply to Jim Mathies [:jimm] from comment #5)

Hey Pulse, curious do you see the same issue in Chrome?

@jimm

I don't use Chrome but I installed to test this issue. From what I can see, going full screen in Minecraft, has no effect on Chrome but does affect Firefox release and nightly.

One additional piece of information, I play different versions of Minecraft and I noticed that this border issue doesn't happen when using 1.12.2 but does when using 1.16.5. Same Java version/settings.

Comment 7

[Darkspirit]

(Darkspirit from bug 1730991 comment #0)

Ubuntu 21.04, Nvidia GTX 1060, driver 470,

• MOZ_X11_EGL (bug 1695933)
• manually enabled GPU process

I could reproduce bug 1719003 with xfce (xubuntu-desktop) when disabling compositing (Applications > Settings > Window manager tweaks > Compositing). I assume the fat black border is due to browser.tabs.drawInTitlebar=true. Before disabling compositing, it was fine.
Seconds later Nightly became shortly black (=GPU process crash).

After restarting Nightly, the fat black border was gone.
My impression: If Firefox decided on startup to use tabs in titlebar, it can't handle sudden deactivation of compositing.

Comment 8

[Darkspirit]

Attachment: Screenshot_20210916_021016.png

Even the "File" menu of xfce4-terminal is affected by this bug. (Have restarted Nightly since disabling composition, but not the terminal.)

Comment 9

[Robert Mader [:rmader]]

So this is a tricky one, potentially requiring a lot of effort to fix in Firefox. The problem is that there are two very different methods to handle window shadows:

• use the Xshape X11 extension (legacy for non-composited environments)
• use visuals with alpha channels (composited environments - IIRC that is everywhere besides certain X11 WMs. Windows Vista also had it under certain circumstances)

Basically we'd need to re-initialize all windows every time the compositing mode changes - or use them in a combined fashion, but drivers have shown to not like that, especially the prop. nvidia one.

I'd like to argue that this should simply get fixed in XFCE. If XFCE dynamically turns off composition when a fullscreen game is started, it could as well turn it on again once the game is not in focus any more. That is how e.g. Gnome handles unredirection. Requiring every app and toolkit to be able to dynamically switch between composited and legacy mode is rather much to ask - and maybe a reason why only now accelerated graphics becomes more normal for toolkits such as GTK4.

Pulse: Given that not only Firefox is affected (comment 8) and I image the number of affected applications will rather go up in the future, I'd recommend you to create an issue at https://gitlab.xfce.org/xfce/xfwm4/-/issues/, asking for the above.

Comment 10

[Darkspirit]

Closing as invalid. Not a bug in Firefox.

Comment 11

[Darkspirit]

Attachment: 2021-09-17 18-10-34.mp4

Ubuntu 21.04, KDE X11, GTX 1060, Nvidia driver 470
Exact KDE STR for completeness:
mozregression --launch 2021-09-17 --pref pref gfx.webrender.all:true browser.tabs.drawInTitlebar:true

Press Shift (!) + Alt + F12 to disable compositing: Black borders.
Press it again: Black borders gone.