GNOME Bugzilla – Bug 778216
label disappears and reappears when performing keypress UI actions
Last modified: 2017-10-18 08:20:47 UTC
Created attachment 344993 [details] test case I have been experiencing strange behavior with labels disappearing and reappearing. I've managed to generate a fairly simple test case that reproduces it reliably. Compile the attached application and execute it. Press the following arrow keys in the following order: down, down, right, up You will observe that the label in the first row of the list box disappears. It will reappear if you select its row again or if you click away from the application window.
> dboles raymod2: which OS/backend are you using at the moment? i can't reproduce > here on x11 > raymod2 It manifests on all the OSes I test except Ubuntu (Windows, OS X, > Fedora). > dboles and is your installation of Fedora running Wayland or X as its backend? > raymod2 Whatever is default for Fedora 25. > baedert raymod2: Does GTK_DEBUG=no-css-cache fix it? > raymod2 baedert - yes! > baedert dup of https://bugzilla.gnome.org/show_bug.cgi?id=763517 then > bugbot Bug 763517: .General, normal, gtk-bugs, NEEDINFO , Selected sidebar item > in file chooser briefly has wrong color on cursor leave > baedert which is ages old and nobody knows the css cache code well enough *** This bug has been marked as a duplicate of bug 763517 ***
Created attachment 344995 [details] expected output
Created attachment 344996 [details] actual output
Until this bug gets fixed it can be suppressed with the following line of code: gtk_set_debug_flags(gtk_get_debug_flags() | GTK_DEBUG_NO_CSS_CACHE); However, this might incur a performance penalty.
There appear to be a lot of bugs that are suppressed by disabling CSS caching. That doesn't mean they are all the same issue. Reopening this to get more eyes on it. Since there is a simple test case that reliably reproduces it this should be fairly easy to triage.
The duplicate also implicates GtkListBox, like yours, and also places particular emphasis on the first (or last) row thereof. So, these are almost certainly facets of the same problem, and fragmenting info about that problem is not useful, so I would say we do not need two of these. *** This bug has been marked as a duplicate of bug 763517 ***
I think you missed my point. I provided a simple test case here (unlike in the other bug report). That makes it much easier to reproduce and debug the problem here. Closing this bug report wastes the effort I expended writing the test case. But since it doesn't seem like this is every going to get fixed I guess it's a moot point.
> No one has so yet tracked down and fixed the exact cause for free does not equate to > it doesn't seem like this is every going to get fixed Nor does it mean your test case will be ignored. But thanks for the passive aggressive sarcasm, which is useful and doesn't seem immature or self-centred at all.
Let's lay off the personal attacks, Daniel. We're all working towards the same goal here. I'm merely trying to express that your repeated attempts to close this bug report (without fixing the issue) are not helpful.
Right, I apologise for the stupid comment I made; if I interpret something as having a negative tone, it doesn't help for me to respond in a negative way. My finger will remain firmly off the Status button on this one.
Please confirm whether the fix at https://bugzilla.gnome.org/show_bug.cgi?id=763517#c29 addresses this.
Cannot reproduce this anymore with a gtk+ that contains https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=8439f06500ba4e6f4a7b52351e67c579509ef903, closing.