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 757397 - gtk_widget_set_name() doesn't properly refresh the style
gtk_widget_set_name() doesn't properly refresh the style
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Class: GtkStyleContext
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-10-31 00:44 UTC by Colomban Wendling
Modified: 2015-11-01 01:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example reproducing the bug (2.19 KB, text/x-csrc)
2015-10-31 00:44 UTC, Colomban Wendling
  Details
cssnode: Fix style updating when the CSS node ID changes (1.78 KB, patch)
2015-10-31 22:15 UTC, Colomban Wendling
committed Details | Review

Description Colomban Wendling 2015-10-31 00:44:29 UTC
Created attachment 314523 [details]
example reproducing the bug

Setting the CSS ID (`gtk_widget_set_name()`) on a widget doesn't trigger a repaint even when required.  OTOH, setting a CSS class does work properly.

Interestingly, unsetting the ID (`gtk_widget_set_name(widget, NULL)`) properly refreshes, but not setting one (i.e. `gtk_widget_set_name(widget, "dummy")`).

Attached a small test case reproducing the issue.  If all worked OK, the text should blink red.  You can build with `-DUSE_STYLE_CLASS` to use style classes instead of IDs, which makes the example work as expected.

Tested broken on 3.18.0 and Git HEAD; 3.16.0 worked.


Adding `GTK_CSS_CHANGE_ID` to `GTK_CSS_RADICAL_CHANGE` in `gtkcssnode.c` fixes (or works around) the issue; but I don't have enough clues about this code to know whether this would be a sensible fix.  If it is though, it might be sensible to use `GTK_CSS_CHANGE_ANY_SELF` instead, as it has the same value and (to my eyes) might make sense.
Comment 1 Colomban Wendling 2015-10-31 01:04:02 UTC
Just finished bisecting, and the offending commit is https://git.gnome.org/browse/gtk%2B/commit/?id=4ebb5781eaf332da3f8ce5ffb5ecc8668a56f118

So I suspect the solution of adding `GTK_CSS_CHANGE_ID` to `GTK_CSS_RADICAL_CHANGE` is correct, and probably also the one of using `GTK_CSS_CHANGE_ANY_SELF` directly.
Comment 2 Colomban Wendling 2015-10-31 22:15:40 UTC
Created attachment 314561 [details] [review]
cssnode: Fix style updating when the CSS node ID changes

Proposed patch fixing the issue.  I also altered gtkcsswidgetnode.c in the same way just in case as it probably suffers from similar issues (as NAME used to include ID), although it doesn't seem to be required to fix the actual issue I'm seeing.  I can remove this change if it's deemed unnecessary and/or incorrect.

(In reply to Colomban Wendling from comment #0)
> If it is though, it might be sensible to use `GTK_CSS_CHANGE_ANY_SELF` instead, as it has the same value and (to my eyes) might make sense.

Scratch that, it was too late for my eyes to see only the first few constants were the same, the value of those are actually totally different.
Comment 3 Benjamin Otte (Company) 2015-11-01 01:43:37 UTC
Attachment 314561 [details] pushed as f4c3006 - cssnode: Fix style updating when the CSS node ID changes