I'm having exactly the same issue.

Linux (Arch); Openbox 3.6.1; FF 66.0.2

Note this seems to break mouse move events in hamburger popup atm, though I swear I had seen it work on top of 480668:84318ef3fa4f, though now can't get it to

argh.... ignore that - moz-phab or hg munged a bunch of uncommitted files in with my commit

Note this seems to break mouse move events in hamburger popup atm, though I swear I had seen it work on top of 480668:84318ef3fa4f, though now can't get it to.

This patch is not ideal... I had tried undoing bits of 1406533, but that didn't work.

So, partly I made the accelerated path head to shaped=1 via mHasAlpha = false so that the shaping would work.
However, then I realized that an accelerated window does not work as WindowSurfaceX11Surface is not involved (and that's where the shape code currently lives)

Anyways, I'm posting here just to see if it sparks discussion

Hi, I think you want to look at WindowSurfaceProvider::CreateWindowSurface() to see which backend is actually created in your case when you see the black borders....maybe add some logging there or so.

(In reply to graham sanderson from comment #28)

Note this seems to break mouse move events in hamburger popup atm

That's bug 1567791.

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

Hi, I think you want to look at WindowSurfaceProvider::CreateWindowSurface() to see which backend is actually created in your case when you see the black borders....maybe add some logging there or so.

So my change to nsWindow::WidgetTypeSupportsAcceleration in place, we get a WindowSurfaceX11Surface (as a result of BasicCompositor calling StartRemoteDrawingInRegion from BeginFrame).
... without it, we use CompositorOGL and WindowSurfaceProvider::CreateWindowSurface is never called.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #31)

(In reply to graham sanderson from comment #28)

Note this seems to break mouse move events in hamburger popup atm

That's bug 1567791.

Thanks - this patch does work except for that issue, though it may not be the actually correct fix. It seems to be very tied up in what is in and out of process too

According to https://github.com/orgs/FirefoxGraphics/projects/1, "Start Replacing Skia" is planned in Q4.
It seems the long term plan is to use the EGL codepath, and for blacklisted drivers everything on top of SwiftShader.
Downgrading shaped OpenGL/WebRender widgets to Basic (Skia) widgets doesn't look like a long-term solution to me. But I'm not a developer.

Chromium's panels are not shaped and begin slightly above the line of death. When using KDE without compositing, it shows solid borders instead of smooth shadows. Imitating Chromium's behavior could be a fallback solution, if approved.

Yup anything but the black borders :-) ... my patch only targets popup windows with non webrender (I think) acceleration under non composited X11.
Note with the patch you indeed do not get the shadows, but you do get the pointy part of the popup at the top and no black border

Note i believe the black borders only occurs for linux with forced acceleration on (perhaps that is now the default)... but in this case not accelerating popups might be reasonable

layers.acceleration.force-enabled;true (called "OpenGL" compositing on about:support) is the old accelerated compositor. The new OpenGL-based compositor is "WebRender". It can be force-enabled with gfx.webrender.all;true (restart needed) and it's already enabled by default on Linux Nightly.

If you fix black borders for OpenGL compositing by downgrading shaped widgets to Basic, the fix would likely be obsolete next year.
(And bug 1567791 would then have to fix "shaped Basic widgets within the GPU process" instead of changing such widgets (back) to WebRender.
Basic is rather not intended to be used within the GPU process. And long-term plan seems to replace Basic with WebRender/SwiftShader as non-accelerated fallback solution.)

OK that makes sense... i.e. fixing this bug properly by including shaped window support in the accelerated path.

I did not realize that WebRender was intended as a solution for all devices (i also had thought it required Wayland) ; i will take a closer look.

(Jan Andre Ikenmeyer [:darkspirit] from bug 1633574 comment 8)

Created attachment 9143849 [details]
Screenshot_20200428_024316.png

Activated autoscroll and scrolled a bit down.

It's most likely the same "shaped Basic in GPU process" bug as bug 1567791, but won't be fixed by bug 1574746. Basic should not be used in GPU process.
bug 1574746 will fix bug 1567791 by upgrading main menu, identity panel and page actions menu from Basic to OpenGL. (That introduces a black background behind the main menu like webextension panels already have. That's the same behavior the OpenGL compositor always had.)

With bug 1622633 (WebRender for context menu, autoscroll, tooltips), the autoscroll icon would get a black rectangle as background as well.

bug 1479135 might fix these black backgrounds of shaped widgets on non-compositing window managers by "including shaped window support in the accelerated path".
I have confirmed that https://www.ssec.wisc.edu/~billh/bp/shape.c achieves a shaped OpenGL context. It looks similar to what has been done for Basic: https://hg.mozilla.org/mozilla-central/rev/6af61c29b5497d864fd7c1ceac0084590b097218 ("XShapeCombineMask")

Martin, would https://www.ssec.wisc.edu/~billh/bp/shape.c be a solution for this?

Is this the disabled-by-default/deprecated "XRender" code path? I tried gfx.xrender.enabled, but it does not fix this problem. How should this ideally be fixed, or could this be fixed at all, if EGL should be used in the future? Sorry for my naive questions.

I have found the following code snippet in which I see usage of EGL together with XCreateGC and XCreatePixmap:
https://fossies.org/linux/mesa-demos/src/egl/opengl/xeglgears.c
This makes me assume that XShapeCombineMask could work with EGL as well.
So, I assume, this bug could be an optional fix after bug 788319 or a wontfix ("I have grown accustomed to it.").
I am sorry that I'm not able to provide better help than providing possible hints.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #41)

Martin, would https://www.ssec.wisc.edu/~billh/bp/shape.c be a solution for this?

Yes, this may be used to fix it.

Martin, this bug is gathering a bunch of duplicates and many +1s in the comment, is there a solution as a patch for our upcoming releases or a workaround for affected users that we could document on SUMO? Thanks

(In reply to Pascal Chevrel:pascalc from comment #48)

Martin, this bug is gathering a bunch of duplicates and many +1s in the comment, is there a solution as a patch for our upcoming releases or a workaround for affected users that we could document on SUMO? Thanks

It's related to Bug 1663273 - let's look at this one when Bug 1663273 lands.

(In reply to Pascal Chevrel:pascalc from comment #48)

Martin, this bug is gathering a bunch of duplicates and many +1s in the comment, is there a solution as a patch for our upcoming releases or a workaround for affected users that we could document on SUMO? Thanks

A workaround is to enable compositing in desktop environment. Users may need to disable compositing (rendering with alpha blending) mainly on KDE to improve rendering performance. And this bug is caused by disabled screen compositing and enabled WebRender in Firefox.

Let's disable WebRender for popups on non-compositing screens. There's no much point to disable compositing when HW rendering is used so it's a bit corner case. Also to fix it on WebRender side we'd need to implement shape mask rendering in the rust code and I don't think we want to spend time on it.

Not sure how happy the GFX team will be with that (they are already preparing to drop accelerated layers), but I guess we still have time till the basic backend will we dropped.

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

Not sure how happy the GFX team will be with that (they are already preparing to drop accelerated layers), but I guess we still have time till the basic backend will we dropped.

That's needs to be done on gfx side, no matter if WR or SW-WR is used. But don't block WR enrollment on Linux by it right now.

If we want to uplift this for the 84 release, we need to request it today.

I don't think we need to uplift as it's a bit corner case and WebRender is not used by default yet.

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

I don't think we need to uplift as it's a bit corner case and WebRender is not used by default yet.

WebRender is used by default for GNOME/X11 in 84 for AMD/Intel users.

(In reply to Andrew Osmond [:aosmond] from comment #58)

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

I don't think we need to uplift as it's a bit corner case and WebRender is not used by default yet.

WebRender is used by default for GNOME/X11 in 84 for AMD/Intel users.

I see, then we're safe here. Non-compositing scenario is used on KDE/XFCE only, Gnome does not support non-compositing screens. Also how about Wayland, is WebRender enabled also there?

If you say 84, you mean 84 beta, not upcoming 84 release, right?

Excellent, KDE/XFCE are 84 early beta only. GNOME/X11 + Intel/AMD will ride the trains to 84 release. This excludes XWayland.

Right now Wayland users get WebRender up to early beta, although it doesn't ship out to release.

(In reply to Andrew Osmond [:aosmond] from comment #61)

Excellent, KDE/XFCE are 84 early beta only. GNOME/X11 + Intel/AMD will ride the trains to 84 release. This excludes XWayland.

Right now Wayland users get WebRender up to early beta, although it doesn't ship out to release.

I sure we can also enable WebRender on Wayland/GNOME/Intel/AMD, it's pretty well tested because Gnome is running on Wayland/GL only, there's no SW rendering there at all.

EDIT: Also Wayland backend affects Fedora only right now so I'd like to enable it there too.

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

I sure we can also enable WebRender on Wayland/GNOME/Intel/AMD, it's pretty well tested because Gnome is running on Wayland/GL only, there's no SW rendering there at all.

EDIT: Also Wayland backend affects Fedora only right now so I'd like to enable it there too.

See bug 1680505.

Cool, Thanks!

FYI Raspberry Pi OS ships with a non compositing window manager, so this bug happens there too. I haven't tried a build for Raspberry Pi since the EGL stuff dropped.

https://hg.mozilla.org/mozilla-central/rev/13a85de368de

Webrender now supports using software WR for uncomposited widgets. So once that's enabled we won't use basic any more. gfx.webrender.software.unaccelerated-widget.force should already force this behaviour on nightly and appears to work fine on WMs like fluxbox.

So the workaround here appears to not stop us from removing basic, which again is important in order to simplify certain things in Gecko, which again should allow Webrender to get significant faster where it's currently slow.

I was not able to reproduce the issue on build from description and it is not either reproducing on latest NB 97.0a1 (20211208214306) Win10, nor on Mac 10.13 & Ubuntu 20.4 (96.0b2 - 20211207185904).