The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
The connection between an Animation and an AnimationTimeline is optional. That
is, it is possible to have an Animation without an AnimationTimeline. Until now
we have often just assumed the timeline will be set but eventually we need to
support the possibility of the timeline being null. Indeed, later in this patch
series we will set the timeline out-of-band (i.e. not in the constructor) using
SetTimeline which opens up the possibility that timeline will be null for
a period of time.
This patch paves the way for having an optional timeline by storing the global
used for, e.g. creating promises, on the Animation object itself.
This patch adds a convenience method for getting the transition property for
a CSS transition (so we can use this when ordering CSS transitions).
We already have ElementPropertyTransition::TransitionProperty() so this might
seem to be redundant, however we add this now because:
* In the proposed CSS Transitions <-> Web Animations integration, the
CSSTransition interface has a transitionProperty member so we'll need this
function for that.
* Once we allow script to modify the transition, we'll need to track the
original transition property for sorting purposes which is what this method
should do.
* We'll possibly drop ElementPropertyTransition::TransitionProperty() in the
future.
Similar to the earlier patch in this series that changed the sequence number
handling for animations, this patch re-uses Animation::mSequenceNum to store
the animation generation number when each transition was generated. When the
transition is cancelled it reverts to using the default animation composite
ordering.
Since bug 960465 patch 14, we've retained finished transitions in order
to handle the issues described in
https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The
code that did this made the assumption that the transition manager is
notified of the full sequence of style changes that happen to an
element. However, when an element becomes part of a display:none
subtree and then later becomes displayed again, the transition manager
is not notified of a style change when it becomes displayed again (when
we do not have the old style context).
This patch introduces code to prune the finished transitions when that
happens.
This really fixes only part of the set of problems described in bug
1158431, which also affect running transitions. However, it's the part
of that set that was a regression from bug 960465, which introduced the
retention of finished transitions, and which makes these issues
substantially easier to hit.
I'd like to fix this part quickly because it's a regression and we
should backport the fix.
Without the patch, I confirmed that the following two tests fail:
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5
With the patch, all the added tests pass.
This patch is a fairly minimal rename of the AnimationPlayer interface. It
leaves a bunch of local variables and helper classes still using the word
"player". These will be addressed in subsequent patches that don't require DOM
peer review.
We define KeyframeEffectReadonly in KeyframeEffect.cpp since Web Animations also
defines KeyframeEffect and when we come to implement that I expect we'll define
it in the same class, maybe even using the same object.
This patch also adds a few missing includes in places where
KeyframeEffectReadonly is used so that we're not just cargo-culting it in.
Most of this is fairly obvious. However, the addition of 'override' to
ElementPropertyTransition::Name() is not strictly necessary. It was simply added
because while making these changes I accidentally dropped the 'virtual' keyword
from the method in the superclass and the compiler didn't complain. Adding this
will hopefully make it harder to create the same bug in the future.
This is a bit awkward. We lazily set mName to the transition property and then
return it. The reasons for this approach are:
* We don't really want to eagerly fill in mName for all transitions since in
99% of cases we'll never use it and this will lead to wasted allocations.
* The signature of Name() returns a const nsString reference. This is because
Name() is used when building CSS Animations (to compare different copies of
the same animation when updating). For that case we don't really want to
generate unnecessary copies of nsString objects so we return a reference.
However, that means for transitions as well we need to return a reference so
we can't just generate a temporary string on-demand.
As a result we also have to const-cast ourselves so we can update the mName
member. We could make mName mutable but seeing as it's only set once, the
const_cast seems more appropriate.
This patch adds an options flag to GetAnimationsForCompositor for two reasons.
a) We want to reuse this functionality in nsLayoutUtils.cpp rather than
duplicating the same logic. To do that and maintain the existing behavior,
however, we need to *not* update the active layer tracker when calling this
from nsLayoutUtils.cpp.
b) It's surprising that GetAnimationsForCompositor also has this side effect of
updating the active layer tracker. Adding this as an option makes it clear at
the call site that this is what will happen.
I don't have a test case that requires this, but it seems like a good
idea. (It was an incorrect theory for fixing a test failure that I was
debugging, but still seems worth doing.)
Now that there is a public accessor for mStartTime, we can make it a protected
member of AnimationPlayer. The only time mStartTime is ever set is when playing
the animation so we can replace external modifications to mStartTime with calls
to Play(). This simplifies implementing deferred starting of animations
in bug 927349 by isolating the deferred playback logic to AnimationPlayer.
Note that even when we call PauseFromStyle immediately afterwards we still need
to call PlayFromStyle (or Play) first in order to resolve the time at which the
player should be paused. A newly created player doesn't have a current time so
if we were simply to call pause it wouldn't pause at the start of the animation
as we might expect. The call to Play(FromStyle) will cause the current time to
become zero and then we pause at that time.
nsAnimationManager provides GetAnimationPlayers while nsTransitionManager
provides GetElementTransitions. Both perform the same function, namely, fetching
(and optionally creating if it does not exist) the AnimationPlayerCollection for
the specified element/pseudo. Furthermore, both take the same arguments.
This patch aligns the method names and makes this a virtual method on the base
class CommonAnimationManager so that it can be used generically from a pointer
to a CommonAnimationManager.
