We will need to request a restyle and unregister the current target in
SetTarget(), and there are many duplicate code segments for them now, so wrap
them for reusing the code.
MozReview-Commit-ID: 33XoNspZme3
Use ConvertTarget() to convert Nullabe<ElementOrCSSPseudoElement> into
Maybe<OwningAnimationTarget>, so SetTarget() can use it as well. The return type
of ConvertTarget is not Maybe<NonOwningAnimationTarget> because we need to
compare the return type with KeyframeEffectReadOnly::mTarget, so using the same
type would be easier to implement.
MozReview-Commit-ID: GskbydOMoo0
1. Define OwningAnimationTarget.
2. Replace the KeyframeEffectReadOnly::mTarget/mPseudoType members with
a Maybe<OwningAnimationTarget> mTarget member.
MozReview-Commit-ID: 65qOoNyDRSy
We set a null target only from Web Animations API, so make sure
KeyframeEffectReadOnly::ConstructKeyframeEffect() can handle null target
properly.
MozReview-Commit-ID: D6PoV7PGFj3
We don't need to restyle if mTarget is nullptr, so skip it. For
nsAutoAnimationMutationBatch, we also skip it if mTarget is nullptr.
AnimationColletion, nsAnimationManager and nsTransitionManger are for
CSS Animations and CSS Transtions, so the effect should have an effective
target. Therefore, I think we don't have to revise them for
nsAutoAnimationMutationBatch.
MozReview-Commit-ID: Egzr1QVEa0v
WebIDL referes to KeyframeEffect::SetFrames(), which is derived from
KeyframeEffectReadOnly::SetFrames() in terms of implementation.
In addition, make KeyframeEffectReadOnly::ConstructKeyframeEffect call
KeyframeEffectReadOnly::SetFrames() to simplify the code.
MozReview-Commit-ID: 7ASbtoN7Tnp
Before switching CSS animations over to using KeyframeEffectReadOnly::SetFrames
we update the getFrames() API to return the set frame objects (when available)
so that we can test that we are setting the correct frames.
MozReview-Commit-ID: 4SpBRM7Ykyv
Earlier in this patch series we divided keyframe processing into two stages:
(1) Turning javascript objects into an array of Keyframe objects
(2) Calculating AnimationProperty arrays from the Keyframe objects
This patch creates a SetFrames method so that CSS animations and
CSS transitions can skip (1) and pass the frames constructed from CSS syntax
into (2).
It also adds the following additional processing:
a. Notifying animation mutation observers when the set of frames has changed.
This is currently performed by nsAnimationManager but ultimately we should
encapsulate this logic inside the effect itself. Furthermore, it will be
needed when we implement effect.setFrames() (i.e. the Javascript-facing
wrapper for this method).
b. Preserving the mWinsInCascade and mIsRunningOnCompositor state on properties
when updating them.
This is currently performed by:
bool KeyframeEffectReadOnly::UpdateProperties(
const InfallibleTArray<AnimationProperty>& aProperties)
which is what nsAnimationManager currently uses. We will ultimately remove
the above method and here we are just moving this code to the new version
of UpdateProperties.
c. Requesting a restyle when the set of AnimationProperty objects has changed.
Again, this is currently performed by the existing UpdateProperties method
so we are just moving it here. This behavior will also be required when
we implement effect.setFrames() and when we call UpdateProperties from
elsewhere in restyling code.
This is bug 1235002 but we fix it here and leave that bug to just do further
cleanup work (e.g. re-instating the check for an empty property set before
requesting a restyle in NotifyAnimationTimingUpdated).
d. Marking the cascade as needing an update when the set of AnimationProperty
objects has changed.
This is in preparation for calling UpdateProperties from elsewhere in
restyling (e.g. when the nsStyleContext is updated).
MozReview-Commit-ID: 2ll26lsWZTm
In KeyframeEffectReadOnly::ComposeStyle we call StyleAnimationValue::Interpolate
but assume that it always passes. That was true when that code was only used for
CSS animations and CSS transitions since they check that their animation values
can be interpolated before setting up segments.
However, when we set up animations using the Web Animations API we don't perform
that check so it is possible for this call to fail.
In that case, we could just bail, but, according to CSS Transitions we should
apply a 50% switch in this case:
https://drafts.csswg.org/css-transitions/#step-types
(In Web Animations, specifying this is an open issue. See:
https://w3c.github.io/web-animations/#specific-animation-behaviors).
Bug 1064937 tracks doing this in general (we'll likely need to mark various
properties as being no longer unanimatable but instead as supporting discrete
animation) but we can start to introduce it now.
Later in bug 1245748, CSS animations and transitions will likely start using
the same code path as the Web Animations API for setting up keyframes.
As a result, unless we take care to add checks that the values we set are
interpolable, the 50% switch behavior will begin to apply to CSS animations and
transitions too at that point.
Some concerns have been raised about possible web compatibility issues around
the 50% switch behavior (see [1] and [2]). For CSS animations, Chrome already
supports this behavior so it should be ok at least for CSS animations.
When we switch CSS transitions over to the same code path, however, we will need
to be careful to add checks that the transition endpoints are interpolable
(we can investigate introducing this behavior to transitions as a separate bug
that can be easily backed out / preffed off).
Regarding the naming of the test added here, going forward we would like to
restructure the tests under web-platform-tests to better match the structure of
the Web Animations since that seems to be the convention there.
However, this doesn't *quite* match the structure of the spec since there are
upcoming changes to the spec in this area (e.g. renaming animation behaviors to
animation types). However, it should be close enough that we don't have to move
it around too much in future.
[1] https://drafts.csswg.org/css-transitions/#step-types
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1064937#c0
MozReview-Commit-ID: KcxILrckJg9
In the next patch in this series, we would like to update the error handling of
the call to StyleAnimationValue::Interpolate in
KeyframeEffectReadOnly::ComposeStyle. Using AnimValuesStyleRule::AddEmptyValue
there, however, makes handling the error case difficult because we need a means
of clearing the allocated StyleAnimationValue.
However, simply using AnimationValuesStyleRule::AddValue means we will end up
doing needless allocations for StyleAnimationValue objects (the copy
constructor for which can result in performing potentially expensive heap
allocations, such as when lists are deep-copied).
Instead, we add a Move constructor to StyleAnimationValue and add an overload
of AnimValuesStyleRule::AddValue that takes an rvalue reference. This
provides a more consistent interface to AnimValuesStyleRule and avoids the
unnecessary allocations from copying StyleAnimationValue objects.
MozReview-Commit-ID: CaP1uPAgNnm
Specifically, for the 'composite' member on keyframes, we now indicate "use the
composite value specified on the effect" using a missing/undefined 'composite'
member as opposed to a null value.
MozReview-Commit-ID: ZH45GvCTlP
We use the parent element of a pseudo element as the subject to be notified.
Usage:
We record animations targeting to pseudo elements by setting subtree attribute
to true.
MutationObserver(Node, { subtree: ture });
So all the animations targeting to the pseudo elements whose parentElement is
the first argument will be recorded.
At the same time we also make the 'warning' member of AnimationPropertyDetails
no longer nullable and simply use the absence of the member to indicate "no
warning" (which is what we were already doing -- we were never actually setting
it to null).
MozReview-Commit-ID: HdRDbqhCdmw
I think the reason we originally didn't do this is that the
"isRunningOnCompositor" status might be misleading for animations that are
being overridden. That is, there are some animations we don't send to the
compositor because they are being overridden by another animation (e.g. a
CSS animation touching the 'transform' animation will cause a CSS transition
on the same property not to run, despite the fact that transitions apply
higher in the cascade). This is not merely a performance optimization but means
we don't have to do the cascade on the compositor.
In the future, once we introduce additive animation, we won't be able to handle
this so simply since it an animation will be able to be partially overridden.
Instead, consumers of this API will need to look at the 'composite' member of
the various animation values to see if an animation is being fully or partially
overridden.
As a result, this API really should return all running animations, even if they
are currently being overridden.
MozReview-Commit-ID: DwmbXdCqF32
We are now extending this API to include more than just metadata about each
animated property but also the property values themselves.
Note that we can't use the name AnimationProperty for the dictionary since
we already use that name internally and [BinaryName] doesn't seem to apply to
dictionaries.
MozReview-Commit-ID: AcXeN4fsgTz
This better matches the order in the WebIDL and, once we rename
GetPropertyState to GetProperties it will make sense for GetFrames and
GetProperties to be side-by-side.
MozReview-Commit-ID: 67s9WGksPFv
Later in this patch series when we convert tests from web-platform tests to
mochitest-chrome tests, some of the test cases that use zero-length segments
(overlapping keyframes at certain offsets) would trigger failed assertions
in KeyframeEffectReadOnly::ComposeStyle. This is because this method was
originally written with CSS animations in mind where segments cannot be
zero-length. Furthermore, when these same tests cases are run as
web-platform-tests, the failed assertions are not visible.
This patch adjusts the handling of segments to allow zero-length segments and
adds a test to check that the handling matches that defined in Web Animations
which is summarized in the following informative note,
"this procedure permits overlapping keyframes. The behavior is that at the
point of overlap the output value jumps to the value of the last defined
keyframe at that offset. For overlapping frames at 0 or 1, the output value
for iteration progress values less than 0 or greater than or equal to 1 is the
value of the first keyframe or the last keyframe in keyframes
respectively."[1]
[1] https://w3c.github.io/web-animations/#the-effect-value-of-a-keyframe-animation-effect
MozReview-Commit-ID: JdyYbGZtbot
As well as generally simplifying the different KeyframeEffect(ReadOnly)
constructor methods, this patch also means we will use the realm document for
parsing timing functions in all cases. Although this currently doesn't have
any impact (the current set of timing functions are expected to be parsed
identically regardless of the document used) it may become significant if, in
future, it becomes possible to register hooks with certain documents for
parsing CSS properties as part of the houdini efforts.
MozReview-Commit-ID: 4gAZi1G1uAD
Once we update TimingParams to take a document, we will need to get an
appropriate document within the various constructor methods. This complicates
these methods and suggests they should be pushed into the .cpp file where
we can hide the complexity more easily and templatize the type of the options
argument so that we can share the document-fetching code.
By moving all uses of the declared template methods to the .cpp file we
can drop the explicit instantiations.
(We still need to declare the templated methods in the header file since
these methods need to be protected methods of KeyframeEffectReadOnly in
order to construct a KeyframeEffectReadOnly since its constructor is
protected.)
MozReview-Commit-ID: 8KrCWrWIb7X
