GNOME Bugzilla – Bug 671565
Styles from style class persist after gtk_style_context_remove_class
Last modified: 2014-07-10 03:25:50 UTC
Even after a style class is removed from a style context (with gtk_style_context_remove_class), that style class will continue to contribute styles. This happens because the style class is never removed from the widget_path element, even when the style_data is rebuilt from scratch in style_data_lookup. The attached simple testcase highlights the bug. Although this was discovered and tested for 3.2, a quick perusal of master indicates this bug persists.
Created attachment 209178 [details] main.c
Created attachment 209194 [details] [review] [
Created attachment 209196 [details] [review] [RFC 1/1] Remove style class from widget_path also ** Fat-fingered the earlier attachment description ** This patch removes the style class from the widget_path during gtk_style_context_remove_class. Although this patch does correct the problem, it may be architecturally unsuitable. Other possible options: 1. Clear the existing style classes from the widget_path head when rebuilding style_data (in create_query_path). The problem with this approach is that it will remove classes that have been added with gtk_widget_path_iter_add_class. 2. Remove only this style class from the widget_path head when rebuilding style_data. Not enough information exists when rebuilding style_data to implement this deferral. 3. Force users of style context to gtk_widget_reset_style whenever removing style classes. Not practical -- besides, if this is required to achieve accurate styling, then it should be done within gtk_style_context_remove_class.
Is this bug fixed for 3.6?
Thanks for the testcase. Seems to be reproducible, still.
I think the test is still broken, because 3.6 will not invalidate the style until the next run of gtk_container_idle_sizer(). However, we build widget paths on demand now (and neither use GtkWidget->priv->widget_path nor GtkStyleContext->priv->widget_path anymore), so I think in the real world, this should not happen anymore.
*** Bug 669229 has been marked as a duplicate of this bug. ***