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 763517 - Selected then unselected Label in ListBox gets wrong colour until hovered/backdropped
Selected then unselected Label in ListBox gets wrong colour until hovered/bac...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 746210 764126 764678 771459 776226 778885 783051 785020 786336 786688 787764 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-03-11 22:56 UTC by Sebastian Keller
Modified: 2017-10-10 19:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Theme to test this with (532 bytes, text/css)
2016-09-27 11:47 UTC, Timm Bäder
Details
Testcase (655 bytes, text/plain)
2016-09-27 11:50 UTC, Timm Bäder
Details
Video of GtkListBox not reevaluating :last-child until hover (341.34 KB, video/webm)
2017-07-21 18:30 UTC, Daniel Boles
Details
test cased used in my video (1.18 KB, text/plain)
2017-07-21 18:30 UTC, Daniel Boles
Details

Description Sebastian Keller 2016-03-11 22:56:29 UTC
Steps to reproduce:
1. run gtk3-widget-factory from home
2. click on the file chooser button
3. move the cursor to the "Home" entry in the sidebar
4. move the cursor out again

What you should see is that the text color briefly changes from white to black before changing to white again. This can be repeated multiple times as long as the window is kept open. Once you close and reopen the window it can't be reproduced anymore.

Disabling transitions using the gtk inspector cause this problem to disappear:
* {transition: none;}

Disabling the CSS cache works as well:
env GTK_DEBUG=no-css-cache gtk3-widget-factory
Comment 1 Matthias Clasen 2016-03-13 14:34:36 UTC
I can't reproduce this here
Comment 2 Sebastian Keller 2016-03-13 19:37:56 UTC
After playing around with this some more, I found another thing that could affect the reproducibility:
Once the window has been set to backdrop the bug can't be reproduced anymore either.

I'm guessing there might be some wrong initial value in the cache and anything that triggers an invalidation would fix them so the bug can't be reproduced anymore. Maybe that's also the reason why it works after disabling the transitions in the inspector?

Also I'm running gtk master from jhbuild on F24 in case this is important. I've tried compiling gtk with both gcc and clang in order to test if it was maybe related to gcc 6 which is shipped with F24. But changing the compiler had no effect on the bug.

Please let me know if that helps to reproduce the bug.
Comment 3 Sebastian Keller 2016-03-17 06:24:44 UTC
This happens in other applications using sidebars too. I've seen this now in at least gedit, gnome-logs and nautilus.

I also found another way to trigger what I think is the same bug using nautilus:

- kill all running instances (probably not required, just to be safe)
- open a new window
- open a new tab with the Downloads folder with a middle click
- switch to the first tab again
- navigate to the Downloads folder with a double left click
- switch tabs again

Now every time you switch tabs, the font color of the "Downloads" entry in the sidebar changes to black and stays this way until hovered. Sometimes I've also seen dark gray instead of black.

All this has to happen without switching windows or anything that would trigger the backdrop state.
Comment 4 Cédric Bellegarde 2016-05-18 05:11:20 UTC
*** Bug 764678 has been marked as a duplicate of this bug. ***
Comment 5 Jean-François Fortin Tam 2016-08-02 14:48:47 UTC
Isn't this the same as bug #764126 ?
Comment 6 Matthias Clasen 2016-08-02 15:37:24 UTC
Not obviously
Comment 7 Timm Bäder 2016-08-04 15:24:14 UTC
A few observations
  -
  - With a bit of training and a small test case, one can manage to make the white foreground stick after leaving the window, much like the effect seen in bug #764126
  - This happens only to the first row in a listbox
  - ... and only if that row was selected when it was initally shown (i.e. it actually had white text)
  - ... and only if the row then gets unselected and then hovered
  - ... and only if the hover effect really includes a transition. Removing all transitions from adwaita makes the problem go away
  - When it happens, the label node finds a cached style in the parent cache, i.e. https://git.gnome.org/browse/gtk+/tree/gtk/gtkcssnode.c#n366 returns the style
Comment 8 Matthias Clasen 2016-08-11 16:02:39 UTC
*** Bug 764126 has been marked as a duplicate of this bug. ***
Comment 9 Mohammed Sadiq 2016-09-15 09:00:13 UTC
*** Bug 771459 has been marked as a duplicate of this bug. ***
Comment 10 Timm Bäder 2016-09-27 11:47:04 UTC
Created attachment 336352 [details]
Theme to test this with
Comment 11 Timm Bäder 2016-09-27 11:50:03 UTC
Created attachment 336353 [details]
Testcase

 1) replace the theme/Adwaita/gtk-container.css with the theme above
 2) Recompile gtk+
 3) Run the test case with current gtk+ master (or 3.20 I assume)
 4) Click the empty space below the first row (which comes up selected)
 5) Now hover the first row
 6) From now on whenever not hovered, the first row has blue text and stays that way.

I briefly suspected a state problem in GtkListBox but the inspector says those are fine.
Comment 12 Matthias Clasen 2016-09-28 10:45:51 UTC
The problem you describe does not happen if I add your replacement theme fragment with a separate provider.
Comment 13 Timm Bäder 2016-09-28 10:47:36 UTC
I know; the point is to eliminate everything from Adwaita that could interfere with the problem, thus you need to replace the theme/Adwaita/gtk-contained.css (or use some other means of not loading Adwaita).
Comment 14 Ernestas Kulik 2016-12-18 08:33:12 UTC
*** Bug 776226 has been marked as a duplicate of this bug. ***
Comment 15 Daniel Boles 2017-02-05 20:21:34 UTC
*** Bug 778216 has been marked as a duplicate of this bug. ***
Comment 16 Ernestas Kulik 2017-02-19 18:13:26 UTC
*** Bug 778885 has been marked as a duplicate of this bug. ***
Comment 17 Ernestas Kulik 2017-07-17 13:35:03 UTC
*** Bug 785020 has been marked as a duplicate of this bug. ***
Comment 18 Ernestas Kulik 2017-07-17 13:37:41 UTC
*** Bug 783051 has been marked as a duplicate of this bug. ***
Comment 19 Daniel Boles 2017-07-17 13:55:56 UTC
I'm having a go at renaming this, in the hope of helping it show up in the list of suggestions while people are starting to file duplicates; hopefully this is better, but please feel free to improve it further.
Comment 20 Daniel Boles 2017-07-21 18:30:10 UTC
Created attachment 356138 [details]
Video of GtkListBox not reevaluating :last-child until hover

Dunno if it helps at all, as it's probably just another facet of the same problem, but fwiw I noticed that ListBox also doesn't reevaluate a margin on > *:not(:last-child) until the OLD last-child is hovered.
Comment 21 Daniel Boles 2017-07-21 18:30:51 UTC
Created attachment 356139 [details]
test cased used in my video
Comment 22 Daniel Boles 2017-08-03 19:16:48 UTC
*** Bug 778216 has been marked as a duplicate of this bug. ***
Comment 23 Daniel Boles 2017-08-15 17:48:15 UTC
*** Bug 786336 has been marked as a duplicate of this bug. ***
Comment 24 Daniel Boles 2017-08-23 16:25:08 UTC
*** Bug 786688 has been marked as a duplicate of this bug. ***
Comment 25 Daniel Boles 2017-08-24 21:40:48 UTC
*** Bug 746210 has been marked as a duplicate of this bug. ***
Comment 26 Rui Matos 2017-09-18 13:05:51 UTC
*** Bug 787764 has been marked as a duplicate of this bug. ***
Comment 27 Daniel Boles 2017-10-09 11:47:07 UTC
*** Bug 750663 has been marked as a duplicate of this bug. ***
Comment 28 Timm Bäder 2017-10-09 16:28:33 UTC
Also interesting to note: If you take attachment 336353 [details] and replace the GtkFrame with just a GtkListBoxRow (so GtkListBox doesn't insert a row between frame and list), the problem does not occur.
Comment 29 Timm Bäder 2017-10-10 19:46:08 UTC
For the record, I was able to shrink the css snippet even more:

/* This transition is important */
row {
  transition: color 1ms linear;
}

/* We need BOTH of these */
row:selected>label,
row:selected
{
  color: #0f0; /* The first row will take this color when not hovered */
}

and the test case:
#include <gtk/gtk.h>

void
main (int argc, char **argv)
{
  gtk_init ();
  GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  GtkWidget *listbox = gtk_list_box_new ();
  GtkWidget *label = gtk_label_new ("FOO");
  GtkWidget *label2 = gtk_list_box_row_new ();

  gtk_widget_set_size_request(label2, -1, 50);
  gtk_widget_set_size_request(label, -1, 50);

  gtk_container_add (GTK_CONTAINER (listbox), label);
  gtk_container_add (GTK_CONTAINER (listbox), label2);
  gtk_container_add (GTK_CONTAINER (window), listbox);

  g_signal_connect (window, "delete-event", gtk_main_quit, NULL);
  gtk_widget_show (window);
  gtk_main ();
}


This bug should be fixed by https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=8439f06500ba4e6f4a7b52351e67c579509ef903 though.