Top corners of Firefox windows have weird black protrusions from the rounded edges
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Medium
|
|||
firefox (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Image to illustrate the problem is attached. All firefox windows on Wayland (EDIT: and X11) have a weird black protrusion from the top-left and top-right corners where yaru has curved the window corners, but something from Firefox appears to not be being clipped by the theme. I need to double check whether this appears on X11, but for now consider it Wayland only until I report back, although oSoMoN has checked their system and they don't see the behaviour (on X11).
EDIT: I have now checked X11 on my system and I see the same behaviour as described above, so this is affecting BOTH Wayland AND X11 for me.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: firefox 75.0+build3-
ProcVersionSign
Uname: Linux 5.4.0-21-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.11-0ubuntu25
Architecture: amd64
BuildID: 20200403170909
CurrentDesktop: ubuntu:GNOME
Date: Wed Apr 8 14:48:56 2020
InstallationDate: Installed on 2020-03-03 (35 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200303)
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
In Mozilla Bugzilla #1509931, 89c51 (barz621) wrote : | #7 |
The same thing happens on linux also.
https:/
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #8 |
I'm not sure how to fix that on Wayland as it does not support XShape mask which we use on X11.
In Mozilla Bugzilla #1509931, 5-greg (5-greg) wrote : | #9 |
huh, the corners were just masked out? But who draws the non-transparent gray pixels there in the first place?
In Mozilla Bugzilla #1509931, Jan Steffens (heftig) wrote : | #10 |
Created attachment 9121264
Default and Light theme corners, GNOME Shell window screenshots, scale 2, on striped background
This almost works for me, and the behavior is the same whether basic layers or WR is used.
As I understand, the way CSD works here is that the window uses a GTK window style which only draws the shadow around an inner widget drawn by Firefox. Adwaita gives us a soft shadow and a 1px semitransparent outline.
The Default theme has a slight glitch where the corners are not as transparent as they should be. I think the tab bar's "headerbar" styling is trying to draw a window shadow here which gets overlaid with the shadow drawn by the window. We need to either somehow remove the shadow from the headerbar style applied to the tab bar, or somehow mask out the drawing of the window shadow so that it only draws outside the inner widget.
The Light and Dark themes have no "headerbar" styling, so the tab bar has sharp corners which clash with the rounded outline from the window's Adwaita theme.
In Mozilla Bugzilla #1509931, Limpid-mazarine (limpid-mazarine) wrote : | #11 |
Hi, the issue still exists on Firefox 74.0 on Fedora (Wayland). Any idea how to fix this?
Lucy Llewellyn (lucyllewy) wrote : | #1 |
- top-right corner of a Firefox window on Wayland Edit (19.1 KiB, image/png)
- Dependencies.txt Edit (4.9 KiB, text/plain; charset="utf-8")
- HookError_source_firefox.txt Edit (757 bytes, text/plain; charset="utf-8")
- ProcCpuinfoMinimal.txt Edit (1.3 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (115 bytes, text/plain; charset="utf-8")
Lucy Llewellyn (lucyllewy) wrote : | #2 |
- top-right corner of a Firefox window on X11 Edit (6.9 KiB, image/png)
I'm also seeing the pattern when logged-into X11 (note there is a difference in the image because in Wayland I have the monitor set to 200% scaling while in X11 it is set to 100%, so the images have different numbers of pixies for the bug)
description: | updated |
description: | updated |
Olivier Tilloy (osomon) wrote : | #3 |
I'm seeing a similar artifact in top corners of firefox windows under wayland, although it looks more transparent in my focal VM. But it's not present under X11.
Changed in firefox (Ubuntu): | |
status: | New → Confirmed |
Lucy Llewellyn (lucyllewy) wrote : | #4 |
- with menubar in title bar (buggy) Edit (420.7 KiB, image/png)
This is specific to the unification of the menu-bar into the title-bar through client-side decorations. I am about to attach two more screenshots that show the difference when the unification is disabled vs the default.
Lucy Llewellyn (lucyllewy) wrote : | #5 |
Changed in firefox: | |
importance: | Unknown → Medium |
status: | Unknown → New |
Sebastien Bacher (seb128) wrote : | #12 |
Thanks but it's a minor cosmetic issue and not impacting our default session so we don't consider it as a release issue, tagging rls-ff-notfixing
tags: |
added: rls-ff-notfixing removed: champagne |
Changed in firefox: | |
status: | New → Confirmed |
In Mozilla Bugzilla #1509931, Felix Pojtinger (pojntfx) wrote : | #13 |
I can confirm this issue still exists in Fedora 34, Firefox 89, Wayland.
In Mozilla Bugzilla #1509931, Robert Mader (robert.posteo) wrote : | #14 |
This just became even more prominent in 95 with colorways. We need a way to support this with alpha visuals as XShape is neither available on Wayland nor on X11 with HW Webrender - i.e. it's only available in legacy fallback paths. As the default theme supports this (even though with a grey corner), I suppose this is not really a graphics but rather a theme issue.
Emilio, do you happen to know how the default theme gets its corners and what would need to be done to make it work for other themes as well?
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #15 |
Wayland case seems to be a bit special as it produces gray corner even with Gtk theme (which works OK on X11/Alpha).
We may want to draw alpha over corners when custom theme is used and main window is not maximized or tiled.
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #16 |
I'm not quite familiar with how this works, I think Martin is the right person to ask about it.
I can dig if you want but I'd guess that this kind of stuff (the `:not(:
In Mozilla Bugzilla #1509931, Robert Mader (robert.posteo) wrote : | #17 |
Thanks emilio, that's a good hint. The comment says
> It may cause performance issues so let's put it under a preference and enable it for desktop environment which do that by default.
This is clearly outdated and from a pre Webrender time.
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #18 |
Emilio, you're absolutely right :) There's original Bug 1408360 for it.
For custom themes we need to apply alpha component only and keep original color from theme (i.e. paint over alpha from theme).
Emilio, how is the best way how to do it? We can introduce a new appearance (-moz-window-
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #19 |
*** Bug 1706752 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #20 |
(In reply to Martin Stránský [:stransky] (ni? me) from comment #11)
> Emilio, how is the best way how to do it? We can introduce a new appearance (-moz-window-
I don't think that's super-great, I think I have an idea which should be relatively simple, stealing.
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #21 |
Created attachment 9246287
Bug 1509931 - Add support for chrome-only environment variables. r=stransky
This bit is taken straight from D73454 (I reviewed it but I guess
another pair of eyes is ok, it's really straight-forward).
Co-authored-by: Nicklas Boman <email address hidden>
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #22 |
Created attachment 9246288
Bug 1509931 - Expose titlebar radius as a chrome-only CSS environment variable. r=stransky
Mostly plumbing.
Depends on D128679
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #23 |
Created attachment 9246289
Bug 1509931 - Use titlebar radius on Linux and make titlebar set-up work for lightweight themes. r=stransky!,dao!
Depends on D128680
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #24 |
Created attachment 9246290
Bug 1509931 - Remove -moz-gtk-
We always use alpha visual for WebRender, and appearance: none is
unnecessary (root element has no intrinsic appearance).
Depends on D128681
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #25 |
Created attachment 9246291
Bug 1509931 - Simplify titlebar buttons CSS. r=stransky
There's no need to use the media query to set the default styles of the
buttons, we only need to hide them if appropriate.
Depends on D128682
In Mozilla Bugzilla #1509931, W-jan-k (w-jan-k) wrote : | #26 |
(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)
> Created attachment 9246290
> Bug 1509931 - Remove -moz-gtk-
>
>
> We always use alpha visual for WebRender
KDE with disabled compositor, i3, etc. use alpha visual, but it's not transparent.
Could -moz-gtk-
and be used to forbid outer border-radius + outer shadow of main menu/addon/etc. widgets
to remove any Xshape usage (bug 1730991 comment 6)?
According to the Chromium bugtracker, Xshape also causes performance problems (bug 1730991 comment 7).
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #27 |
(In reply to Darkspirit from comment #19)
> KDE with disabled compositor, i3, etc. use alpha visual, but it's not transparent.
WDYM, just that the background wouldn't be transparent?
> Could -moz-gtk-
> and be used to forbid outer border-radius + outer shadow of main menu/addon/etc. widgets
> to remove any Xshape usage (bug 1730991 comment 6)?
> According to the Chromium bugtracker, Xshape also causes performance problems (bug 1730991 comment 7).
I'm not sure about this (not familiar with XShape at all).
This patch stack makes Wayland look great, but on X11/XWayland I still see the compositor shadow drawn around the crisp corner when using a lightweight theme... Do you know whether that's avoidable Martin?
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #28 |
Ah, I think I know why that might be...
In Mozilla Bugzilla #1509931, Pulsebot (pulsebot) wrote : | #29 |
Pushed by <email address hidden>:
https:/
Simplify titlebar buttons CSS. r=desktop-
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #30 |
Created attachment 9246314
Bug 1509931 - Use a more precise toolbar radius. r=stransky
This seemed possible/maybe worth doing, but let me know if you'd rather
keep the 10 hard-coded.
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #31 |
I fixed the wayland overdraw and the X11 artifacts, so I think this is ready to go. I've tested this stack on KWin and GNOME, both X11 and Wayland. Will test i3 and such asap.
In Mozilla Bugzilla #1509931, W-jan-k (w-jan-k) wrote : | #32 |
(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)
Non-composited X11 (the legacy variant of X11: i3, KDE with manually disabled compositor, etc.) does not support transparency. Everything that would usually be transparent/alpha is just black/opaque. Menus and window corners had [shadows on black background](https:/
The autoscroll icon was a [black square with a white circle](https:/
[XShapeCombineM
XShapeCombineMask is not implemented for hardware rendering.
That's why SW WR is enforced for menus, addons and autoscroll icon on non-composited X11 to make use of XShapeCombineMask while the main window is still using OpenGL.
XShapeCombineMask
* caused problems on [Mutter](https:/
* crashes the GPU process on Nvidia: bug 1730991
* causes performance problems according to the Chromium bugtracker: bug 1733094 comment 18,https:/
Could XShapeCombineMask be removed and instead menus and the autoscroll icon loose their border-radius (become rectangular) and loose their shadow (to avoid black background) if gdk_screen_
IIUC, that would reduce code complexity, improve stability and performance.
A rectangular autoscroll icon on non-composited X11 would be noticeable. But users choose non-composited X11 to get more performance than with composited X11. Considering this as well, it doesn't make sense to use XShapeCombineMask which contradicts their intent and causes above problems.
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #33 |
Well, perhaps, but that seems tangential to this bug, isn't it? We don't use XShapeCombineMask for the titlebar and this patch stack doesn't start doing that.
If we do want to do the cleanup described above, we might need a new media query which determines this (but it should definitely not have `csd` in the name, since it is not about csd at all). So I'd rather clean up the existing one since it's confusing at best.
Anyways, things I've tested:
* KWin (Wayland/
* GNOME (Wayland/
* i3
* bspwm
And in all cases this patch stack doesn't regress behavior (and improves it in the obvious cases). So I'd say comment 25 should be a separate bug?
If someone has an exotic setup and wants to give this a try before it lands, or wants to provide feedback, builds should be here eventually: https:/
In Mozilla Bugzilla #1509931, W-jan-k (w-jan-k) wrote : | #34 |
(In reply to Emilio Cobos Álvarez (:emilio) from comment #26)
> If we do want to do the cleanup described above, we might need a new media query which determines this (but it should definitely not have `csd` in the name, since it is not about csd at all). So I'd rather clean up the existing one since it's confusing at best.
> And in all cases this patch stack doesn't regress behavior (and improves it in the obvious cases). So I'd say comment 25 should be a separate bug?
Yes. I only remembered that a query like `-moz-gtk-
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #35 |
Created attachment 9246335
titlebar CSS rounded borders properties
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #36 |
btw. It would be great to get border-radius from menu elements (Adwaita uses it) and use it in gecko too, for context menus for instance. But that may be a different bug.
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #37 |
So, querying the individual border-radius properties doesn't work. I get:
> (firefox:17330): Gtk-WARNING **: 00:39:54.651: Style property "border-
And same for the other corners of course. However, my patch works, because of [this code](https:/
So given there's no way to access the other border corners, and that this works for our purposes, I think we should probably just roll with it, thoughts?
In Mozilla Bugzilla #1509931, Robert Mader (robert.posteo) wrote : | #38 |
(In reply to Emilio Cobos Álvarez (:emilio) from comment #30)
> So given there's no way to access the other border corners, and that this works for our purposes, I think we should probably just roll with it, thoughts?
I'd agree - should work well for almost everyone.
One question I had to think of is if we want to use rounded corners at the bottom at some point - more and more GTK4 apps do that, e.g. nautilus/files. But we can also leave that for the future.
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #39 |
Okay, fair enough.
In Mozilla Bugzilla #1509931, Imoraru (imoraru) wrote : | #40 |
In Mozilla Bugzilla #1509931, Pulsebot (pulsebot) wrote : | #41 |
Pushed by <email address hidden>:
https:/
Add support for chrome-only environment variables. r=stransky
https:/
Expose titlebar radius as a chrome-only CSS environment variable. r=stransky
In Mozilla Bugzilla #1509931, Pulsebot (pulsebot) wrote : | #42 |
Pushed by <email address hidden>:
https:/
Remove -moz-gtk-
https:/
Use a more precise toolbar radius. r=stransky
In Mozilla Bugzilla #1509931, Pulsebot (pulsebot) wrote : | #43 |
Pushed by <email address hidden>:
https:/
Fix rebase mistake.
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #46 |
Emilio, I tested the patches and it looks great!
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #47 |
Emilio, when running testsuite with the patch (locally) I'm getting this crash:
2:05.41 GECKO(53217) Assertion failure: sInServoTraversal || NS_IsMainThread(), at /home/komat/
2:05.41 GECKO(53217) #01: mozilla:
2:05.41 GECKO(53217) #02: mozilla:
2:05.41 GECKO(53217) #03: nsresult mozilla:
2:05.41 GECKO(53217) #04: mozilla:
2:05.41 GECKO(53217) #05: nsXPLookAndFeel
2:05.41 GECKO(53217) #06: nsWindow:
2:05.41 GECKO(53217) #07: nsWindow:
2:05.41 GECKO(53217) #08: mozilla:
2:05.41 GECKO(53217) #09: mozilla:
2:05.41 GECKO(53217) #10: mozilla:
2:05.41 GECKO(53217) #11: <webrender:
2:05.41 GECKO(53217) #12: webrender:
2:05.41 GECKO(53217) #13: webrender:
2:05.41 GECKO(53217) #14: webrender:
2:05.41 GECKO(53217) #15: wr_renderer_render [gfx/webrender_
2:05.41 GECKO(53217) #16: mozilla:
2:05.42 GECKO(53217) #17: mozilla:
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #48 |
May nsWindow:
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #49 |
We have a technical debt here as we don't use titlebar rendering in testsuite - I'll look at it.
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #50 |
Yeah, so `nsWindow:
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #51 |
(In reply to Emilio Cobos Álvarez (:emilio) from comment #43)
> Yeah, so `nsWindow:
I can fix that as a part of Bug 1736518.
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #52 |
Oh, great, let me know if I can help. Probably a static atomic integer in nsLookAndFeelGtk is slightly easier to invalidate in practice.
In Mozilla Bugzilla #1509931, Stransky (stransky) wrote : | #53 |
*** Bug 1673079 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #1509931, Gschram (gschram) wrote : | #54 |
I have just tested the latest nightly on Fedora 35 and it works perfectly for XWayland, however, when running Wayland the bottom corners are still not rounded and the top corners are rounded but still have a weird (barely noticeable unless you know) transparent sharp corner. Note that I am running a [patched version of mutter](https:/
I understand that this is an edge case currently (with the patched mutter) but I foresee this becoming a "problem" when in a year or two all other apps also have rounded bottom corners and Firefox is the odd one out, I think fixing this now is a good idea to prevent technical debt.
[Xwayland screenshot](https:/
[Wayland screenshot](https:/
[Other apps screenshot](https:/
In Mozilla Bugzilla #1509931, Pulsebot (pulsebot) wrote : | #55 |
Pushed by <email address hidden>:
https:/
Use titlebar radius on Linux and make titlebar set-up work for lightweight themes. r=stransky,dao
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #56 |
(In reply to gschram from comment #47)
> I understand that this is an edge case currently (with the patched mutter) but I foresee this becoming a "problem" when in a year or two all other apps also have rounded bottom corners and Firefox is the odd one out, I think fixing this now is a good idea to prevent technical debt.
Getting bottom corners rounded on Wayland seems worth a separate bug.
In Mozilla Bugzilla #1509931, Gschram (gschram) wrote : | #57 |
(In reply to Emilio Cobos Álvarez (:emilio) from comment #49)
> (In reply to gschram from comment #47)
> > I understand that this is an edge case currently (with the patched mutter) but I foresee this becoming a "problem" when in a year or two all other apps also have rounded bottom corners and Firefox is the odd one out, I think fixing this now is a good idea to prevent technical debt.
>
> Getting bottom corners rounded on Wayland seems worth a separate bug.
I have opened a separate bug here https:/
In Mozilla Bugzilla #1509931, Ccozmuta (ccozmuta) wrote : | #58 |
Changed in firefox: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #1509931, Beatrice-acasandrei (beatrice-acasandrei) wrote : | #59 |
== Change summary for alert #32637 (as of Mon, 06 Dec 2021 09:45:12 GMT) ==
### Improvements:
| **Ratio** | **Test** | **Platform** | **Options** | **Absolute values (old vs new)**|
|--|--|--|--|--|
| 5% | [tresize](https:/
| 5% | [tresize](https:/
| 5% | [tresize](https:/
| 4% | [tresize](https:/
For up to date results, see: https:/
In Mozilla Bugzilla #1509931, Catalin-sasca-z (catalin-sasca-z) wrote : | #60 |
Created attachment 9254735
dim corners.png
Verified on 96.0a1 and 97.0a1 that the top side is rounded and look good on Wayland session under Ubuntu 20.04. Although while getting the notification to make Firefox as default, a dim effect is active and the rounded parts have corners because of that (see attachment and zoom in). Any idea? Thank you!
In Mozilla Bugzilla #1509931, Emilio (emiliocobos) wrote : | #61 |
Bug 1745419 will fix that.
In Mozilla Bugzilla #1509931, Catalin-sasca-z (catalin-sasca-z) wrote : | #62 |
Thanks! Then I will set the flags accordingly.
In Mozilla Bugzilla #1509931, Mikolov73 (mikolov73) wrote : | #63 |
I have posted a bug #1744496 in which I explain that on elementary OS 6.0 Odin the corners are still square. It seems on elementary OS `-moz-window-
Created attachment 9027623 wayland- corner. png
firefox-
(continuing from bug 1507608)
When GL compositing is used on the Wayland backend, the GL subsurface that actual Firefox content is rendered to does not have rounded corners. It overdraws the parent GTK surface that contains the border and shadow.
The Default Firefox theme actually draws the Adwaita rounded corner, but the surface is still not transparent in the corners, so there's an ugly gray corner.