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 774431 - Menuitem style is not invalidated on animated css theme
Menuitem style is not invalidated on animated css theme
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
https://bugzilla.mozilla.org/show_bug...
Depends on:
Blocks:
 
 
Reported: 2016-11-14 20:54 UTC by Martin Stransky
Modified: 2017-11-19 16:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
testcase (1.90 KB, text/plain)
2016-11-14 20:54 UTC, Martin Stransky
Details

Description Martin Stransky 2016-11-14 20:54:53 UTC
Created attachment 339830 [details]
testcase

See the simple testcase. On Gtk 3.22.2 (Fedora 25) when menuitem theme is animated (I tested Menta) the prelight state is not rendered. The bug affects only when css transition rule is present.

The style invalidation seems to be related to direction change, when I add a simple hack to Firefox code which switch style direction for menuitem the style is refreshed correctly as far I can say:

state = gtk_style_context_get_state(style);

if (state & STATE_FLAG_DIR_LTR)
  state &= ~(STATE_FLAG_DIR_LTR);
else
  state |= (STATE_FLAG_DIR_LTR);

gtk_style_context_set_state(style, state);
Comment 1 Martin Stransky 2016-11-14 21:05:56 UTC
Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1315668
Comment 2 Benjamin Otte (Company) 2016-11-14 21:34:10 UTC
I suspect this is caused by the difference between style contexts created by widgets and those created from widget paths. The behavior of updating works different for those.

Actually, there's 4 different cases in the GTK code:
- GtkCssNode
  The default case. Used only by gadgets, so not relevant here. Does run
  animations.
- GtkCssTransientNode
  The one used if you gtk_style_context_save(). Does not run animations and does
  not influence the surrounding CSS tree.
- GtkCssPathNode
  The one used if you create a style context from a widget path. Will not run
  animations and causes the style context's invalidate signal to trigger.
- GtkCssWidgetNode
  The one used if you create a style context from a widget. It runs animations
  and causes a delayed emission of the style context's and widget's invalidate
  signals, so that those are only emitted at most once per frame.

So if you take a style context for a widget and try to reuse it for multiple elements with different states inside the Firefox codebase, you will run into problems, because the associated node will work hard to avoid updates. And everytime it does do an update, it will (re)start animations and transitions.

You can either create one widget node per element - and that way can keep animations - or you should use a widget path node instead if you want to share the style context.
Comment 3 Daniel Boles 2017-11-19 15:54:58 UTC
Is there any real bug here? (Other than the void callback that returns gboolean!)

I see that Firefox moved to using paths, and if the observed behaviour of widget contexts is expected, it seems like there's not really a problem.
Comment 4 Benjamin Otte (Company) 2017-11-19 16:36:57 UTC
I suppose everything got resolved about this one.