gtk_widget_clear_path called too late, causing incorrect style after class removal
Steps to reproduce
- Make a container that overrides get_path_for_child
- Add a child
- Define a class style that changes the widget's appearance
- Set the class
- Observe the widget appearance changes to reflect new behavior
- Remove the class
Current behavior
6a. Widget appearance does not change immediately; may change after style transition, inspector close, etc.
Expected outcome
6b. Widget appearance changes immediately to reflect removal of CSS class
Version information
3.22.24; code inspection indicates problem is still present in GTK4 master
Additional information
Widgets cache their paths via the "gtk-widget-path" quark and this cached path isn't invalidated immediately when the CSS style changes. Instead, we forget this path only in response to the style-changed CSS node signal, which is sent only after lazy style recomputation. The first style recomputation after a style change uses the old path! The problem isn't apparent when adding adding a style class: the CSS selector matching code checks for classes on both the widget node itself and on the path entry for the widget. But after we remove a CSSS class, the removed CSS class is still present on the old cached GtkWidgetPath, so the CSS selector matching gets a false-positive match and fails to update the visual appearance of the widget to reflect the removed style.