GNOME Bugzilla – Bug 738841
Regression in GTK+ 3.12 in handling CSS-defined selected_bg_color
Last modified: 2016-01-10 19:44:28 UTC
Wireshark moved to setting selected text's background color via CSS
 when the method used in GTK+ 2.x stopped working based on the
suggestion at .
It works fine on wheezy (see first attached image) using GTK+ 3.6 but
stopped working on Jessie (see second attached image) with GTK+ 3.12.
I tested it using Homebrew and with GTK+ 3.14 this also fails and as I
remember GTK+ 3.10 worked OK.
The problem has been reported to Debian's BTS first, please see che screenshots there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763034#5
3.14.1 still has the problem.
That looks pretty random. Why is it redefining themed colors that are likely already defined by the theme, instead of just using the rgb values in the css directly ?
Named colors in GTK have historically been rather undefined and up to the theme to define. Whenever there are substantial changes to the theme (Adwaita itself has seen substantial rewrites over the course of GTK 3 and when switching themes nothing is guaranteed at all).
So if color names do work, it's usually more luck than anything else.
The suggested way is to use gtk_style_context_save(), gtk_style_context_set_state(), gtk_style_context_add_class() and gtk_render_background() or gtk_style_context_get_color() for rendering instead of relying on color names.
As a clunky backwards-compatibility mechanism, Adwaita supports some color names that we realized applications were using via https://git.gnome.org/browse/gtk+/tree/gtk/theme/Adwaita/_colors-public.scss so it might be possible as a short-term fix to fall back to those in Wireshark.
We might also want to extend those named colors with the names from your links, though I'll leave that to the themes people.
Lets not add more named colors