This changes the coalescing behavior during the animation-only style
flush by doing tree-based coalescing between the style updates required
by animations and those required by transitions, rather than doing
animations and transitions separately.
Note that both the old and the new code update all
animating/transitioning styles rather than only the throttled styles,
though we should fix that eventually as noted in the FIXME comment in
the code (but only for the existing caller, and not for the new one to
be introduced in bug 960465).
Note that this depends for its correctness on the previous patches to
make the restyling process exact.
The test changes are because the effects of bug 1031688 are changed by
the change in coalescing. In the old code, we updated transition styles
before animation styles; in the new code we do a single pass over the
tree, which for the relevant test means updating animations on the
parent before transitions on the child, which changes the effects of the
bug.
This will be necessary when we use the restyle tracker for the
animation-only style flush, because animation-only style flushes need to
update *only* the animation style data and no other style data. Thus
using the RestyleTracker for animation-only style flushes requires that
we do this.
Note that we're not yet using this code for style contexts that have
pseudo-elements, since we don't run transitions or animations on
pseudo-elements on the compositor thread. But bug 960465 will (with
some more work) start doing so.
The added test passes locally on Linux with OMT compositing and OMT
animations enabled. However, it also passes without the patch because
the calls to FlushAnimations and FlushTransitions from
PresShell::FlushPendingNotifications cover up the damage done by bugs in
the animation-only style flush.
Unfortunately due to lack of global history on B2G and not running OMT
animations tests on any other platforms, the new test won't actually run
in automation right now.
ResolveStyleForRules had various problems: it failed to set importance
correctly and really only handled replacing a path in the rule tree
since it didn't handle creating important rules. (Possibly more.)
This means ResolveStyleWithReplacement will replace only the rules in
the nsRestyleHint rather than always replacing both the animations rule
and the transitions rule. (This will become even more useful later when
we add the ability to replace the style attribute rule.)
This is the start of a refactoring of the existing code in
CommonAnimationManager, nsTransitionManager, and nsAnimationManager,
which will be removed in later patches (after patches in between cause
this code to be used instead of the current code).
But it also handles interesting cases more correctly, such as cases
where style context parents are unusual.
FIXME: It would be nice to add tests for these cases, but they're mostly
pretty obscure (e.g., a transition of 'transform' that's affected by
inheriting 'transform' from ::first-line), so I'm not treating it as a
priority right now.
FIXME: Adjust for eRestyle_Force if bug 931668 lands first.
Later patches will add such types that are like eRestyle_Self but that
only replace the style attribute, animation rule, or transition rule.
I believe this will fix some cache misses in the FindChildWithRules
lookup when restyling. I don't think it will fix any correctness bugs
because the RelevantLinkVisited() bit will always end up set to true
anyway as the non-link descendant of a visited link style context, and
link descendants shouldn't be able to share styles with non-link
descendants due to matching rules in the UA style sheet.
