I can't reproduce this here

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.

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.

*** Bug 764678 has been marked as a duplicate of this bug. ***

Isn't this the same as bug #764126 ?

Not obviously

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

*** Bug 764126 has been marked as a duplicate of this bug. ***

*** Bug 771459 has been marked as a duplicate of this bug. ***

Created attachment 336352 [details]
Theme to test this with

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.

The problem you describe does not happen if I add your replacement theme fragment with a separate provider.

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).

*** Bug 776226 has been marked as a duplicate of this bug. ***

*** Bug 778216 has been marked as a duplicate of this bug. ***

*** Bug 778885 has been marked as a duplicate of this bug. ***

*** Bug 785020 has been marked as a duplicate of this bug. ***

*** Bug 783051 has been marked as a duplicate of this bug. ***

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.

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.

Created attachment 356139 [details]
test cased used in my video

*** Bug 778216 has been marked as a duplicate of this bug. ***

*** Bug 786336 has been marked as a duplicate of this bug. ***

*** Bug 786688 has been marked as a duplicate of this bug. ***

*** Bug 746210 has been marked as a duplicate of this bug. ***

*** Bug 787764 has been marked as a duplicate of this bug. ***

*** Bug 750663 has been marked as a duplicate of this bug. ***

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.

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.