[CSD] The CSD rendered by GTK have sharp corners

RESOLVED FIXED in Firefox 64

Status

()

defect
P3
normal
RESOLVED FIXED
2 years ago
2 months 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)

(Assignee)

Description

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

a year ago
Blocks: gtktitlebar
No longer blocks: 1399611

Comment 4

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

Comment 5

a year 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

a year ago
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

a year ago
Duplicate of this bug: 1452033

Updated

11 months ago
Duplicate of this bug: 1461613
(Assignee)

Updated

8 months ago
Assignee: nobody → stransky
(Assignee)

Comment 10

8 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

8 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

8 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

8 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

8 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

8 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

8 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

8 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 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+
(Assignee)

Updated

8 months ago
Duplicate of this bug: 1415477
(Assignee)

Updated

8 months ago
Blocks: 1442755
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

8 months ago
Keywords: checkin-needed
(Assignee)

Updated

8 months ago
Blocks: 1489097
(Assignee)

Comment 26

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

Comment 27

8 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

8 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

8 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

8 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

7 months ago
Blocks: 1489963
(Assignee)

Updated

7 months ago
No longer blocks: 1489963

Comment 32

7 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

7 months ago
Duplicate of this bug: 1491548

Comment 34

7 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

7 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

7 months ago
Blocks: 1495023
(Assignee)

Updated

7 months ago
Blocks: 1496349

Comment 36

3 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

2 months ago
Depends on: 1526867
You need to log in before you can comment on or make changes to this bug.