Closed Bug 1408360 Opened 7 years ago Closed 6 years ago

[CSD] The CSD rendered by GTK have sharp corners

Categories

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

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla64
Tracking Flags:
Tracking Status
firefox64 --- fixed

People

(Reporter: stransky, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

corners.png
(deleted), image/png
Details
Bug 1408360 - Create GtkHeaderBar widget at once, r=jhorak
(deleted), text/x-phabricator-request
jhorak
: review+
Details
Bug 1408360 - Draw window decoration as a part of the GtkHeaderBar widget, r=jhorak
(deleted), text/x-phabricator-request
jhorak
: review+
Details
Bug 1408360 - Make toplevel window transparent under mozilla.widget.titlebar-theme-round-corners pref, r=jhorak
(deleted), text/x-phabricator-request
jhorak
: review+
Details
Bug 1408360 - Make toplevel window transparent when mozilla.widget.titlebar-theme-round-corners is set, r=dao
(deleted), text/x-phabricator-request
dao
: review+
Details
round_corners_with_border.png
(deleted), image/png
Details
Attached image corners.png (deleted) — 
Probably due to GDK_DECOR_BORDER mShell decoration type the corners have sharp and not rounded corners.
I thought non-rounded tabs were intentional in Firefox 57+
I mean corner of application toolbar, not the tabs. Sorry for the confusion.
There's a downstream bugs with details: https://bugzilla.redhat.com/show_bug.cgi?id=1506996
Blocks: gtktitlebar
No longer blocks: 1399611
This looks good on the latest build (20171117100127) using the Arc Gtk theme. https://imgur.com/a/waw1F
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.
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
Assignee: nobody → stransky
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.
GtkWindow decoration is a part of GtkHeaderBar widget so we need to include
that in our GtkHeaderBar paint.

Depends on D4663
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
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
(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...
(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.
> 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).
(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.
(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.
(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.
(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 on attachment 9005166 [details]
Bug 1408360 - Create GtkHeaderBar widget at once, r=jhorak

Jan Horak [:jhorak] has approved the revision.
Attachment #9005166 - Flags: review+
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.
Attachment #9005167 - Flags: review+
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.
Attachment #9005168 - Flags: review+
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.
Attachment #9005170 - Flags: review+
Follow up is filed as Bug 1489097 - make round corners default.
Pushed by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6615b44439f9
Create GtkHeaderBar widget at once, r=jhorak
Keywords: checkin-needed
Pushed by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/76b493351fd7
Draw window decoration as a part of the GtkHeaderBar widget, r=jhorak
Pushed by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7b006f2910cc
Make toplevel window transparent under mozilla.widget.titlebar-theme-round-corners pref, r=jhorak
Pushed by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e7ce94bb130b
Make toplevel window transparent when mozilla.widget.titlebar-theme-round-corners is set, r=dao
No longer blocks: 1489963
Attached image round_corners_with_border.png (deleted) — 
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
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.
(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

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
Depends on: 1526867

This is happening again in Ubuntu 19.04 with Firefox 67.0.1

Regressions: 1469716

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?

@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

(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

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?

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.

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.

Flags: needinfo?(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.

Flags: needinfo?(xerz)

(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.

Flags: needinfo?(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").

Flags: needinfo?(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.

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

(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.

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.

(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!

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.

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

Attachment

General

Creator:
Created:
Updated:
Size: