[CSD] The CSD rendered by GTK have sharp corners

RESOLVED FIXED in Firefox 64

Status

()

defect
P3
normal
RESOLVED FIXED
2 years ago
18 days ago

People

(Reporter: stransky, Assigned: stransky)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Trunk
mozilla64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(6 attachments)

Posted image corners.png
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+
Assignee

Comment 2

2 years ago
I mean corner of application toolbar, not the tabs. Sorry for the confusion.
Assignee

Comment 3

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

Updated

2 years ago
Blocks: gtktitlebar
No longer blocks: 1399611

Comment 4

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

Comment 5

2 years ago
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

Last year
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
Duplicate of this bug: 1445675

Updated

Last year
Duplicate of this bug: 1452033

Updated

Last year
Duplicate of this bug: 1461613
Assignee

Updated

10 months ago
Assignee: nobody → stransky
Assignee

Comment 10

10 months 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

10 months 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

10 months 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

10 months 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
(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

10 months 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

10 months 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

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

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

10 months ago
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 22

10 months 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.
Attachment #9005167 - Flags: review+
Assignee

Updated

10 months ago
Duplicate of this bug: 1415477
Assignee

Updated

10 months ago
Blocks: 1442755

Comment 24

10 months 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.
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+
Assignee

Updated

10 months ago
Keywords: checkin-needed
Assignee

Updated

10 months ago
Blocks: 1489097
Assignee

Comment 26

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

Comment 27

10 months ago
Pushed by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6615b44439f9
Create GtkHeaderBar widget at once, r=jhorak
Keywords: checkin-needed

Comment 28

10 months 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

10 months 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

10 months 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
Depends on: 1489499
Assignee

Updated

10 months ago
Blocks: 1489963
Assignee

Updated

10 months ago
No longer blocks: 1489963

Comment 32

10 months 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

Updated

10 months ago
Duplicate of this bug: 1491548

Comment 34

9 months 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

9 months 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
Assignee

Updated

9 months ago
Blocks: 1495023
Assignee

Updated

9 months ago
Blocks: 1496349

Comment 36

5 months 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

Updated

5 months ago
Depends on: 1526867

Comment 37

18 days ago

This is happening again in Ubuntu 19.04 with Firefox 67.0.1

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