It's not need to be a template function since the function is independent from
AnimationType.
MozReview-Commit-ID: 13WkRIfaQbZ
--HG--
extra : rebase_source : 5df3eb22dc2785b43718f388a9a32915a18c8be2
It's not need to be a template function since the function is independent from
AnimationType.
MozReview-Commit-ID: 13WkRIfaQbZ
--HG--
extra : rebase_source : 27232c58c6af439a46cb6c86b0858062ac1fcadb
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
We need a utility method to get the AnimationCollection by dom::Element
and the pseudo element tag.
MozReview-Commit-ID: KCOY6EKFFX5
--HG--
extra : rebase_source : de1b9386d6324cfb4cee0d84b13a0b1af4aa5c12
Rather than passing around a bool flag to indicate if we should be creating
an AnimationCollection when none is found, it would be a lot easier to read
if we simply introduce a separate method for this.
MozReview-Commit-ID: 6bg8jGoH5pL
By moving GetAnimationCollection to AnimationCollection itself, we can remove
a bunch of virtual methods on the animation managers, simplify call sites,
and provide better type safety by ensuring a correspondence between element
property names and concrete animation types.
One change in behavior, however, is that in doing this we can no longer
add any newly-created AnimationCollection to the corresponding manager's linked
list of collections inside GetAnimationCollection. Instead we take a bool
outparam to indicate if a new collection was created and leave managing the
linked list to the manager. This is just a temporary measure, however, since
by the end of this patch series will will eliminate this linked list altogether
along with this flag.
MozReview-Commit-ID: 1jsc4QcmVDg
This patch templatizes the type of Animation stored in an AnimationCollection.
This allows us to remove a number AsCSSAnimation() calls in nsAnimationManager.
This patch also removes the AnimationPtrArray typedef. In its place we
introduce OwningCSSAnimationPtrArray and OwningCSSTransitionPtrArray but we
don't use these as widely. There was some comment previously that the typedefs
in animation code make it hard to read, particularly when these typedefs don't
make it clear if the data type is an owning reference or not.
In doing this we need to templatize CommonAnimationManager as well and move the
implementation of its (few) methods to the header file. We may be able to
remove the need for templatizing CommonAnimationManager later in this patch
series depending on how we ultimately decide to handle the lifetime of
AnimationCollection objects.
CommonAnimationManager::GetAnimationCollection is a bit messy but this will be
significantly tidied up in subsequent patches in this series.
MozReview-Commit-ID: 3ywatY53pRR
In this bug we will trim off unnecessary functionality from the animation
managers and make AnimationCollection into an independent data type
so in this patch we separate it into its own file.
It is also generally easier to navigate the source code and eliminate
cyclic dependencies between header files when there is a rough
correspondance between class names and file names (e.g. rather than having
#include "AnimationCommon.h" // For mozilla::AnimationCollection).
This patch also makes a few simplifications to include dependencies since
they're a bit of a mess (making it hard to move code around). The changes to
IncrementalClearCOMRuleArray.cpp are due to the changes to the unified build
introduced by adding AnimationCollection.cpp exposing a missing include from
that file.
