After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731365 - Problem with "border-color" property on the popover's arrow
Problem with "border-color" property on the popover's arrow
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkPopover
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-06-08 01:20 UTC by Victor Eduardo
Modified: 2018-04-15 00:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of the issue (47.32 KB, image/png)
2014-06-08 01:20 UTC, Victor Eduardo
Details
Screenshot of the issue on Gtk 3.18 (79.58 KB, image/png)
2015-12-05 17:48 UTC, Daniel Fore
Details
Screenshot of the fixed rendering (7.71 KB, image/png)
2016-03-28 12:01 UTC, vvort
Details
popover_fix_v2 rendering with default clipping (9.67 KB, image/png)
2016-04-04 11:20 UTC, vvort
Details

Description Victor Eduardo 2014-06-08 01:20:30 UTC
Created attachment 278093 [details]
Screenshot of the issue

Please see attached screenshot. The border color here is set to “alpha (#000, 0.3)” You can see that the arrow's border is a different color because the popover background is being drawn behind it instead of being clipped like the other sides of the widget.
Comment 1 Victor Eduardo 2014-06-08 01:34:44 UTC
It appears GtkPopover is using 'cairo_stroke' for the arrow's border (L889, gtkpopover.c), and this doesn't respect the background-clip property.

The rectangle's borders are rendered using 'gtk_render_frame_gap', and it properly applies background-clip.
Comment 2 Sébastien Wilmet 2015-10-17 12:31:56 UTC
It seems to be fixed in GTK+ 3.18, at least with the Adwaita theme.

Can you still reproduce the bug?
Comment 3 Sébastien Wilmet 2015-12-04 19:11:42 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!
Comment 4 Sébastien Wilmet 2015-12-04 19:18:30 UTC
It's actually fixed, try this CSS snippet in the GTK+ inspector:

GtkPopover {
	border-color: red;
}

So it's no longer the background-clip property, it's border-color.
Comment 5 Daniel Fore 2015-12-04 21:19:53 UTC
Hey Sébastien, The issue is not fixed as of Gtk 3.18. As noted in the original report, you can reproduce the issue by using a transparent (not solid) border color.
Comment 6 Sébastien Wilmet 2015-12-05 09:47:17 UTC
Works fine here, try:

GtkPopover {
	border-color: alpha (#ff0000, 0.3);
}
Comment 7 Daniel Fore 2015-12-05 17:48:52 UTC
Created attachment 316811 [details]
Screenshot of the issue on Gtk 3.18

Please see the screenshot taken today (December 5th) with Gtk 3.18.5

This popover has a semi-transparent border: alpha (#000, 0.3)

You can see that along the edges of the popover you get very sharp, crisp borders over both light and dark backgrounds. However, the arrow appears blurry. This is because the border is being drawn on top of the arrow instead of around it. It's not being "clipped" as the other portions of the popover background are.
Comment 8 Timm Bäder 2015-12-06 15:33:00 UTC
FWIW, drawing the border over the background is how CSS gets drawn, e.g. https://jsfiddle.net/rapLz4vx/ and 4d075cf202ae428652 made GtkPopover do exactly that for the rest of it. That looks like http://i.imgur.com/hSTd2hk.png currently.

What exactly the issue is here is hard to diagnose, i.e. the color is fine if I just use GDK_SCALE=4 and look at popover borders.

Isn't the issue here more that the box-shadow does not get applied to the tail at all *and* that's just a slim vertical line that gets pixelated?
Comment 9 Daniel Fore 2015-12-06 21:29:58 UTC
@Timm, that is why Victor's comment specifically mentions the background-clip property: https://bugzilla.gnome.org/show_bug.cgi?id=731365#c1

Notice how it changes when you add "background-clip: padding-box;"

If box-shadow applied to the popover tail, that would be a good solution as well. It would fit better with how these borders are applied in other widgets, I think.
Comment 10 Timm Bäder 2015-12-12 14:14:34 UTC
I can make the tail border see-through here: http://i.imgur.com/yqH4yS7.png (not that it's particularly pretty, but at least they don't seem to overlap) and as far as I can see, gtk_popover_get_gap_coords cares about the border-width a lot.
Comment 11 Matthias Clasen 2016-01-08 14:12:30 UTC
Unclear whats missing here. A patch would help
Comment 12 vvort 2016-03-28 12:01:44 UTC
Created attachment 324869 [details]
Screenshot of the fixed rendering

Hello.

Here is my solution to the problem:
https://github.com/Vort/gtk/commit/50a1198231d0e20487cab21e49b0165e6e6ddc75

Please check it.
This is my first patch to GTK project, so there can be newbie mistakes.

One thing that I want to note specially: there is no call to gtk_render_frame_gap in this version.
Comment 13 vvort 2016-03-28 13:45:53 UTC
I have found that my solution works bad in some cases.
I will look if it is possible to modify its algorithm.
Comment 14 vvort 2016-04-04 11:20:22 UTC
Created attachment 325320 [details]
popover_fix_v2 rendering with default clipping

Here is the second version of my fix:
https://github.com/Vort/gtk/commit/1c6457d4f7eb2a1010b6bd456890f8ef08350f87

It uses cairo groups and different composition modes to eliminate the seams between box and arrow objects.
This fix allows to use not only transparent border, but also transparent background (see attachment).
However, its work is not perfect in case of complex backgrounds.

Please take a look at this patch.
Comment 15 Matthias Clasen 2018-02-10 05:22:59 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 16 Matthias Clasen 2018-04-15 00:29:25 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new