It is not correct to stop restyling by leaving the old style context on
the frame and returning eRestyleResult_Stop when TryStartingTransition
provides a new, without-animations style context. This is at least
because the new new style context could have different styles from the
old new style context.
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
This depends on bug 1087536 patch 3, which posts animation restyles
using the eRestyle_CSSTransitions and eRestyle_CSSAnimations hints.
This is used by patch 6.
I don't have any tests that exercise this code, and I can't even find a
codepath that demonstrates that it's needed, since the lazy
reconstruction that happens during style-triggered frame reconstruction
all appears to go through PostRestyleEvent rather than
MaybeConstructLazily.
But I think we should either do this or add an assertion that it's not
needed, and given that it's one line, it seems like we may as well just
do it. (Note also that we're currently calling CreateNeededFrames at
the start of style reresolution, in
RestyleManager::ProcessPendingRestyles; this adds a call at the end.)
Here we call StartRebuildAllStyleData from BeginProcessingRestyles (much
like patch 9 and EndProcessingRestyles). But we will later also call it
from the code that handles a root element font size change when we have
'rem' units. That's because it's fine to *start* the rebuild process in
the middle of processing the queue of pending restyles. (We have to end
after the whole process is done, though, in order to avoid wanting to
destroy the old rule tree while we still have style contexts referencing
it.)
We only call StartRebuildAllStyleData in this case when we're processing
our primary restyle queue (mPendingRestyles), not the animation restyles
(to be removed in bug 960465) or the animation-only restyles, since a
rebuild-all should be processed (in terms of animation phases, or in
terms of having an animation-only update before it) like a normal
restyle. (This isn't true for the 'rem' unit restyle, which could
happen during any sort of update.)
This moves the code that finishes the rebuild-all process into
EndProcessingRestyles(), which is part of the main restyling codepath.
Patch 7 ensures that we'll always get to EndProcessingRestyles in this
case, when we're going through the normal ProcessPendingRestyles()
codepath rather than the special DoRebuildAllStyleData() codepath (which
will be removed later in this patch series).
This is needed for patch 9 (once patch 9 is used via the
ProcessPendingRestyles() codepath in patch 13); it ensures that when we
use the new way of rebuilding, we don't bail out early because we think
we have nothing to do.
This adds a member variable that is currently only used within a single
function, but that function will be split apart so that different parts
of it can be called from different places within ProcessPendingRestyles.
This is the variable that says we *need to* rebuild style data. Since
the next patch will introduce a variable that says we're *currently*
rebuilding all style data, renaming this one makes things clearer.
Part of this refactoring involves the ability to start the rebuild-all
process within the processing of restyles. This means we can't pass
parameters directly from RebuildAllStyleData into DoRebuildAllStyleData.
So this continues storing the hints as member variables a little bit
deeper into the process.
(I tried to move in a different direction in this patch queue, and store
these hints in mPendingRestyles, for the root element. But that broke
layout/style/test/test_counter_style.html and
layout/style/test/test_font_loading_api.html, and I didn't want to
figure out why. It would be somewhat better in the long run, since
currently these hints will get processed if we do a rebuild-all on a
RestyleTracker other than mPendingRestyles, which can happen if we have
'rem' units and have a root element font size change in the
animation-only update or in mPendingAnimationRestyles.)
For some kinds of changes we need to update the layer tree even though there is
no change to style. For example, if an animation is paused via the Web
Animations API, we need to remove the animation from the layer even though the
style will not change.
This patch detects such changes by making ElementRestyler check for an
out-of-date animation generation on layers. This is complicated by the fact that
we currently maintain *two* animation generation numbers: one for the set of
animations and one for the set of transitions, but we only have *one* animation
generation number on each layer. This is a known issue (bug 847286).
As a result, until bug 847286 is fixed, we need to be careful to compare against
the greater of the two numbers.
