[CSD] The CSD rendered by GTK have sharp corners
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: stransky, Assigned: stransky)
References
(Blocks 1 open bug)
Details
Attachments
(6 files)
(deleted),
image/png
|
Details | |
(deleted),
text/x-phabricator-request
|
jhorak
:
review+
|
Details |
(deleted),
text/x-phabricator-request
|
jhorak
:
review+
|
Details |
(deleted),
text/x-phabricator-request
|
jhorak
:
review+
|
Details |
(deleted),
text/x-phabricator-request
|
dao
:
review+
|
Details |
(deleted),
image/png
|
Details |
Probably due to GDK_DECOR_BORDER mShell decoration type the corners have sharp and not rounded corners.
Assignee | ||
Comment 2•7 years ago
|
||
I mean corner of application toolbar, not the tabs. Sorry for the confusion.
Assignee | ||
Comment 3•7 years ago
|
||
There's a downstream bugs with details: https://bugzilla.redhat.com/show_bug.cgi?id=1506996
Assignee | ||
Updated•7 years ago
|
Comment 4•7 years ago
|
||
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
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 10•6 years ago
|
||
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.
Assignee | ||
Comment 11•6 years ago
|
||
GtkWindow decoration is a part of GtkHeaderBar widget so we need to include that in our GtkHeaderBar paint. Depends on D4663
Assignee | ||
Comment 12•6 years ago
|
||
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
Assignee | ||
Comment 13•6 years ago
|
||
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•6 years ago
|
||
(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...
Assignee | ||
Comment 15•6 years ago
|
||
(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•6 years ago
|
||
> 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).
Assignee | ||
Comment 17•6 years ago
|
||
(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•6 years ago
|
||
(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.
Assignee | ||
Comment 19•6 years ago
|
||
(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•6 years ago
|
||
(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•6 years ago
|
||
Comment on attachment 9005166 [details] Bug 1408360 - Create GtkHeaderBar widget at once, r=jhorak Jan Horak [:jhorak] has approved the revision.
Comment 22•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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.
Assignee | ||
Updated•6 years ago
|
Comment 27•6 years ago
|
||
Pushed by aiakab@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6615b44439f9 Create GtkHeaderBar widget at once, r=jhorak
Comment 28•6 years ago
|
||
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
Comment 29•6 years ago
|
||
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
Comment 30•6 years ago
|
||
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
Comment 31•6 years ago
|
||
bugherder |
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
Updated•6 years ago
|
Comment 32•6 years ago
|
||
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•6 years ago
|
||
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.
Assignee | ||
Comment 35•6 years ago
|
||
(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•6 years ago
|
||
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 38•5 years ago
|
||
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•5 years ago
|
||
@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
Comment 40•5 years ago
|
||
(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
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•5 years ago
|
||
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•5 years ago
|
||
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.
Assignee | ||
Comment 43•5 years ago
|
||
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•5 years ago
|
||
(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.
Assignee | ||
Comment 45•5 years ago
|
||
(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•5 years ago
|
||
(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•5 years ago
|
||
(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
Assignee | ||
Comment 48•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
(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•3 years ago
|
||
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.
Description
•