1408360 - [CSD] The CSD rendered by GTK have sharp corners

Status: RESOLVED FIXED

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

Description

[Martin Stránský [:stransky] (ni? me)]

Attachment: corners.png

Probably due to GDK_DECOR_BORDER mShell decoration type the corners have sharp and not rounded corners.

Comment 1

[Jeremy Bicha [:jbicha]]

I thought non-rounded tabs were intentional in Firefox 57+

Comment 2

[Martin Stránský [:stransky] (ni? me)]

I mean corner of application toolbar, not the tabs. Sorry for the confusion.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

There's a downstream bugs with details: https://bugzilla.redhat.com/show_bug.cgi?id=1506996

Comment 4

[Michael Heyns]

This looks good on the latest build (20171117100127) using the Arc Gtk theme. https://imgur.com/a/waw1F

Comment 5

[3ship]

Still present in my installation (20171120100042), also using Arc GTK theme.

On two occasions I had round corners after playing around with customization settings, like activating then deactivating the titlebar. It later reverted, when I had maximized the window. Currently not able to reproduce this.

Comment 6

[moz-nuc]

Corners are per Martin's screenshot on FF58/Fedora 27/Adwaita light GTK+ theme.

BTW, the downstream patch (https://bugzilla.redhat.com/show_bug.cgi?id=1492286 - reverted as of FF58) was working to give rounded corners with CSD. However, it had at least two problems:

* it painted the top edge of unfocused windows with GTK's focused window colour (presumably because Firefox's default Linux theme doesn't change the unfocused window colour either)
* it makes that top ~10 px of the window unthemable via userChrome.css - e.g. https://github.com/kurogetsusai/firefox-gnome-theme can't fix the unfocused colour

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1408360 - Create GtkHeaderBar widget at once, r=jhorak

To get correct style of GtkHeaderBar widget we need to get style of fully
occupied widget with child buttons.

When GtkHeaderBar Gtk+ style is requested create also all child elements
and then return the style.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1408360 - Draw window decoration as a part of the GtkHeaderBar widget, r=jhorak

GtkWindow decoration is a part of GtkHeaderBar widget so we need to include
that in our GtkHeaderBar paint.

Depends on D4663

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1408360 - Make toplevel window transparent under mozilla.widget.titlebar-theme-round-corners pref, r=jhorak

Some Gtk+ themes use non-rectangular toplevel windows. To fully support
such themes we need to make toplevel window transparent with ARGB visual.
It may cause performance issue so let's put it under a preference
and allow distros to enable it per default theme.

Depends on D4664

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1408360 - Make toplevel window transparent when mozilla.widget.titlebar-theme-round-corners is set, r=dao

Some Gtk+ themes use non-rectangular toplevel windows. To fully support
such themes we need to make toplevel window transparent with ARGB visual
and make background of toplevel window transparent.

It may cause performance issue so let's disable it by default and
put it under a preference to allow distros to enable it per default theme.

Depends on D4665

Comment 14

[Dão Gottwald [:dao]]

(In reply to Martin Stránský [:stransky] from comment #12)
> Created attachment 9005168 [details]
> Bug 1408360 - Make toplevel window transparent under
> mozilla.widget.titlebar-theme-round-corners pref, r=jhorak
> 
> Some Gtk+ themes use non-rectangular toplevel windows. To fully support
> such themes we need to make toplevel window transparent with ARGB visual.
> It may cause performance issue so let's put it under a preference
> and allow distros to enable it per default theme.
> 
> Depends on D4664

Under what circumstances would it cause a performance issue? If we don't want to do this by default, why would we want distros to do it? It sounds like we'd be providing them with a footgun...

Comment 15

[Martin Stránský [:stransky] (ni? me)]

(In reply to Dão Gottwald [::dao] from comment #14)
> Under what circumstances would it cause a performance issue? 

Generally with old hardware/broken drivers/non compositing WM.

> If we don't
> want to do this by default, why would we want distros to do it? It sounds
> like we'd be providing them with a footgun.

The transparent/RGBA toplevel windows is AFAIK default on recent DE environment like GNOME/KDE for instance and also Wayland composites by default. Firefox with titlebar disabled looks weird/broken there. But I'm not sure we can make it default now so the pref allows more testing and it doesn't break it for unintended audience.

Comment 16

[moz-nuc]

> and also Wayland composites by default

So at least make it the default when --enable-default-toolkit=cairo-gtk3-wayland is used? (E.g. this is the default for Fedora).

Comment 17

[Martin Stránský [:stransky] (ni? me)]

(In reply to moz-nuc from comment #16)
> > and also Wayland composites by default
> 
> So at least make it the default when
> --enable-default-toolkit=cairo-gtk3-wayland is used? (E.g. this is the
> default for Fedora).

That can be done in another bug.

Comment 18

[Dão Gottwald [:dao]]

(In reply to Martin Stránský [:stransky] from comment #15)
> (In reply to Dão Gottwald [::dao] from comment #14)
> > Under what circumstances would it cause a performance issue? 
> 
> Generally with old hardware/broken drivers/non compositing WM.

Can we detect the non-compositing case without a pref?

As for old hardware and broken drivers, those don't seem like strictly distro-specific factors, so presumably this would be an issue even if we leave it to distros to set the pref.

Comment 19

[Martin Stránský [:stransky] (ni? me)]

(In reply to Dão Gottwald [::dao] from comment #18)
> (In reply to Martin Stránský [:stransky] from comment #15)
> > (In reply to Dão Gottwald [::dao] from comment #14)
> > > Under what circumstances would it cause a performance issue? 
> > 
> > Generally with old hardware/broken drivers/non compositing WM.
> 
> Can we detect the non-compositing case without a pref?

yes, we can detect that at toolkit code and propagate by a media css variable. 

> As for old hardware and broken drivers, those don't seem like strictly
> distro-specific factors, so presumably this would be an issue even if we
> leave it to distros to set the pref.

Sure. There are some performance-oriented lightweight distros which want this disabled, like the ones with default LXDE/XFCE and similar DE.

I support to make this default but I think we should do some test before that and also allow to disable it by pref for performance-oriented lightweight distros.

Comment 20

[Dão Gottwald [:dao]]

(In reply to Martin Stránský [:stransky] from comment #19)
> (In reply to Dão Gottwald [::dao] from comment #18)
> > (In reply to Martin Stránský [:stransky] from comment #15)
> > > (In reply to Dão Gottwald [::dao] from comment #14)
> > > > Under what circumstances would it cause a performance issue? 
> > > 
> > > Generally with old hardware/broken drivers/non compositing WM.
> > 
> > Can we detect the non-compositing case without a pref?
> 
> yes, we can detect that at toolkit code and propagate by a media css
> variable. 
> 
> > As for old hardware and broken drivers, those don't seem like strictly
> > distro-specific factors, so presumably this would be an issue even if we
> > leave it to distros to set the pref.
> 
> Sure. There are some performance-oriented lightweight distros which want
> this disabled, like the ones with default LXDE/XFCE and similar DE.
> 
> I support to make this default but I think we should do some test before
> that and also allow to disable it by pref for performance-oriented
> lightweight distros.

Okay, please make sure to file followups.

Comment 21

[Jan Horak [:jhorak]]

Comment on attachment 9005166 [details]
Bug 1408360 - Create GtkHeaderBar widget at once, r=jhorak

Jan Horak [:jhorak] has approved the revision.

Comment 22

[Jan Horak [:jhorak]]

Comment on attachment 9005167 [details]
Bug 1408360 - Draw window decoration as a part of the GtkHeaderBar widget, r=jhorak

Jan Horak [:jhorak] has approved the revision.

Comment 24

[Jan Horak [:jhorak]]

Comment on attachment 9005168 [details]
Bug 1408360 - Make toplevel window transparent under mozilla.widget.titlebar-theme-round-corners pref, r=jhorak

Jan Horak [:jhorak] has approved the revision.

Comment 25

[Dão Gottwald [:dao]]

Comment on attachment 9005170 [details]
Bug 1408360 - Make toplevel window transparent when mozilla.widget.titlebar-theme-round-corners is set, r=dao

Dão Gottwald [::dao] has approved the revision.

Comment 26

[Martin Stránský [:stransky] (ni? me)]

Follow up is filed as Bug 1489097 - make round corners default.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6615b44439f9
Create GtkHeaderBar widget at once, r=jhorak

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/76b493351fd7
Draw window decoration as a part of the GtkHeaderBar widget, r=jhorak

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b006f2910cc
Make toplevel window transparent under mozilla.widget.titlebar-theme-round-corners pref, r=jhorak

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7ce94bb130b
Make toplevel window transparent when mozilla.widget.titlebar-theme-round-corners is set, r=dao

Comment 31

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/6615b44439f9
https://hg.mozilla.org/mozilla-central/rev/76b493351fd7
https://hg.mozilla.org/mozilla-central/rev/7b006f2910cc
https://hg.mozilla.org/mozilla-central/rev/e7ce94bb130b

Comment 32

[m.kurz]

Attachment: round_corners_with_border.png

This is not entirely fixed for me. The corners a rounded now, however it seems there is a border around the whole firefox window.
The white background in the screenshot correctly shines through, meaning the transparency and rounded corners are working correctly, however there is still a border.

Here are some infos about my environment:

FF Nightly 64.0a1 (2018-09-09) (64-bit)

$ env | grep -i session
DESKTOP_SESSION=gnome-flashback-compiz
XDG_SESSION_TYPE=x11
XDG_SESSION_DESKTOP=gnome-flashback-compiz
GNOME_SESSION_XDG_SESSION_PATH=
GDMSESSION=gnome-flashback-compiz
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
SESSION_MANAGER=local/mkurz-notebook:@/tmp/.ICE-unix/3058,unix/mkurz-notebook:/tmp/.ICE-unix/3058

Comment 34

[jacob.alzen]

Still looks like this isn't fixed when using the latest Nightly version of Firefox. The Windows are still rendered sharp and that makes for some ugly withe dots in the corners.

Comment 35

[Martin Stránský [:stransky] (ni? me)]

(In reply to jacob.alzen from comment #34)
> Still looks like this isn't fixed when using the latest Nightly version of
> Firefox. The Windows are still rendered sharp and that makes for some ugly
> withe dots in the corners.

It's not enabled by default, see Bug 1493145

Comment 36

[Alex Whitman]

This appears to have regressed between 65b11 and 65b12. I've seeing this on two computers running Ubuntu 18.04.

Name              Firefox
Version           65.0b12
Build ID          20190117232427
Update Channel    beta
User Agent        Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
OS                Linux 4.15.0-43-generic

Comment 37

[carlosjosepita]

This is happening again in Ubuntu 19.04 with Firefox 67.0.1

Comment 38

[Xerz]

For a while I noticed this apparent regression, but then realized it only happens when you're using a theme other than the default one. I can only assume this has to be implemented per-theme with the @media (-moz-gtk-csd-transparent-background) rule?

Comment 39

[c.lobrano]

@Xerz,

I can only assume this has to be implemented per-theme with the @media (-moz-gtk-csd-transparent-background) rule?

can you give me more insight on this? Where I can find info about this rule?

I just tested Fedora 30 with Xorgkkk with default Adwaita theme and Firefox 69, the bug is reproducible

https://imagebin.ca/v/4v6HuMQXSXxg

Comment 40

[Xerz]

(In reply to c.lobrano from comment #39)

can you give me more insight on this? Where I can find info about this rule?

I just tested Fedora 30 with Xorgkkk with default Adwaita theme and Firefox 69, the bug is reproducible

https://imagebin.ca/v/4v6HuMQXSXxg

That rule is used within the browser's CSS, and I suspect the background is not properly set to transparent in themes other than the default, or that addons are allowed to draw over the corner in any other way. I know very little about how theming works, so that's as much as I can quickly figure out.

I've been able to reproduce this behavior with both Firefox 69 and the latest 71 nightly, see the following gallery: https://imgur.com/a/aJFYXNV

Comment 41

[c.lobrano]

Thanks, this is interesting.
I can speak for Yaru theme only, but we reuse a very large part of the default GNOME theme, with basic color only modifications. I saw this problem fixed only using Wayland in both Fedora and Ubuntu with default theme.

Is this browser css loaded only under some circumstances?

Comment 42

[Xerz]

OK, so here's what seem to be the relevant parts on enabling the CSD and the required transparency:

https://hg.mozilla.org/mozilla-central/file/c969a93/widget/gtk/nsWindow.cpp#l3652
https://hg.mozilla.org/mozilla-central/file/c969a93/widget/gtk/nsWindow.cpp#l6862
https://hg.mozilla.org/mozilla-central/file/c969a93/widget/gtk/nsWindow.cpp#l6923

Notice a disclaimer which points out to #1516224 as well as #, which justify GNOME on Xorg still not having rounded corners, but the tickets are closed so it should be no longer an issue.

From here on, @media (-moz-gtk-csd-transparent-background) is used to determine if the CSS is applied, as implemented here: https://hg.mozilla.org/mozilla-central/file/c969a93/widget/gtk/nsLookAndFeel.cpp#l680

From what the source code seems to show, this should work just by having a working GNOME desktop, and shouldn't be disabled or enabled in any way due to your specific GTK theme.

Comment 43

[Martin Stránský [:stransky] (ni? me)]

Can you try to find a regression range by https://mozilla.github.io/mozregression/ ? Also which desktop environment do you use? I'm comfused if that's something new or not. Also we don't enable titlebar by default on some systems due to Gtk/Xorg bugs (like Bug 1530252) so when you enable it there are some bugs we can't fix.
Thanks.

Comment 44

[Xerz]

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

Can you try to find a regression range by https://mozilla.github.io/mozregression/ ? Also which desktop environment do you use? I'm comfused if that's something new or not.

I don't think this is a regression at all, but more of a misunderstood bug on its own - I can reproduce the exact same behavior I found with the 71 nightly on Firefox 64.0. If I just use the default Firefox theme the CSD is rendered just as expected, with rounded corners from Adwaita - however, any other Firefox theme will have its background overlaying all of the top, including the parts which are expected to be transparent.

I currently use GNOME Shell 3.30.2.

Comment 45

[Martin Stránský [:stransky] (ni? me)]

(In reply to Xerz from comment #44)

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

Can you try to find a regression range by https://mozilla.github.io/mozregression/ ? Also which desktop environment do you use? I'm comfused if that's something new or not.

I don't think this is a regression at all, but more of a misunderstood bug on its own - I can reproduce the exact same behavior I found with the 71 nightly on Firefox 64.0. If I just use the default Firefox theme the CSD is rendered just as expected, with rounded corners from Adwaita - however, any other Firefox theme will have its background overlaying all of the top, including the parts which are expected to be transparent.

Can you give me come example? For instance I use Yaru (Ubuntu default) and it works as expected, i.e. corners are rounded.

Comment 46

[Xerz]

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

Can you give me come example? For instance I use Yaru (Ubuntu default) and it works as expected, i.e. corners are rounded.

It's not related to the GTK theme, but to the Firefox theme. Just use any Firefox theme, like Light or Dark or an external add-on like any at https://addons.mozilla.org/firefox/themes. A corner that should look fine (as in this example) will not look as expected (as here with "Gradient Sunset").

Comment 47

[c.lobrano]

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

Can you give me come example? For instance I use Yaru (Ubuntu default) and it works as expected, i.e. corners are rounded.

Can you tell me if you're using Xorg or Wayland session?

As said, I can reproduce the bug in both Fedora 30 and Ubuntu 19.04 using default gtk themes (Adwaita and Yaru) in a Xorg session, and Firefox default theme in version 69 as shown here

Comment 48

[Martin Stránský [:stransky] (ni? me)]

(In reply to Xerz from comment #46)

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

Can you give me come example? For instance I use Yaru (Ubuntu default) and it works as expected, i.e. corners are rounded.

It's not related to the GTK theme, but to the Firefox theme. Just use any Firefox theme, like Light or Dark or an external add-on like any at https://addons.mozilla.org/firefox/themes. A corner that should look fine (as in this example) will not look as expected (as here with "Gradient Sunset").

Please file a new bug for it. This is a bit different issue than this one and it happens with Firefox internal themes, not the system ones. Thanks.

Comment 49

[c.lobrano]

A user in Yaru's repository, reported the following

Found that layers.acceleration.force-enabled in about:config removes the white corners (for me) and also shows content with more than 60 FPS too

https://github.com/ubuntu/yaru/issues/179#issuecomment-533831546

I honestly don't know what this means, but I can confirm that in my machine works as well.

Comment 50

[Anwar]

(In reply to c.lobrano from comment #49)

A user in Yaru's repository, reported the following

Found that layers.acceleration.force-enabled in about:config removes the white corners (for me) and also shows content with more than 60 FPS too

https://github.com/ubuntu/yaru/issues/179#issuecomment-533831546

I honestly don't know what this means, but I can confirm that in my machine works as well.

This also worked for me in Firefox 70. Also fixed grayscale antialiasing issue here. A bit strange!

Comment 51

[barnes.t.scott]

This is happening again for me with Firefox 98.0 on Manjaro GNOME using X11. I've tried enabling layers.acceleration.force-enabled but it didn't fix it. Just to be clear, this is using the default Firefox theme, with Manjaro's package of Firefox 98.0 (I disabled Manjaro's customizations too, that didn't change anything). It happens with any rounded GTK theme, including the default Adwaita theme.