When the pending animation having no target element sets a new effect having
a target element associated with a document, PendingAnimationTracker has to
start tracking the animation regardless of mPendingReadyTime.
MozReview-Commit-ID: DxmbXtLhjCT
Before this change, the test in this commit fails. The received events order
is;
1) cancel
2) transitioncancel
3) transitionstart
4) finish
MozReview-Commit-ID: 8liTFXime6e
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
Animation::FlushStyle() gets called only for CSS animations/transitions'
playState changes in JS or ready Promise for CSS animations. In either case
throttled animation state, which is, to be precise, transformed position or
opacity value on the compositor, doesn't affect those results.
The first test case for CSS animations and the first test case for CSS
transitions in this patch fail without this fix.
MozReview-Commit-ID: EVym4qputL4
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
This reflects the change made to the Web Animations specification in:
9e2053f5531c3415f4cc
(I got it wrong the first time. The second commit fixes the first.)
And discussed in:
https://github.com/w3c/web-animations/issues/196
In summary, we are splitting the "pending" play state out into a separate
boolean member so that it is possible to distinguish between "play-pending" and
"pause-pending" and because most of the time when you check for
animation.playState === 'running' you also really want to include play-pending
animations.
MozReview-Commit-ID: IJSNoZTKW2I
When we set the playback rate to zero on a play-pending animation that is
resuming from an aborted pause we can arrive in a state where both the start
time and hold time are resolved. However, we previously added an assertion that
only one of these is ever set at a time.
Part of the assertion is warranted since that method contains the following
code:
if (mStartTime.IsNull()) {
mStartTime = StartTimeFromReadyTime(aReadyTime);
if (mPlaybackRate != 0) {
mHoldTime.SetNull();
}
}
Here StartTimeFromReadyTime requires a non-null hold time. So either mStartTime
or mHoldTime needs to be non-null. The requirement that only one or the other be
non-null, however, is not in the spec and not necessary (as the test cases in
this bug show).
What this assertion does bring to light, however, is that in the case where we
have *both* the start time and the hold time, we need to consider whether to use
the start time as-is, or calculate it from the hold time.
I have filed the following spec issue for this:
https://github.com/w3c/web-animations/issues/200
MozReview-Commit-ID: CTCT7Up1E5n
According to the spec, when we cancel an animation we should "reset an
animation's pending tasks"[1] which has following step:
...
4. Reject animation’s current ready promise with a DOMException named "AbortError".
5. Let animation’s current ready promise be the result of creating a new resolved Promise object.
Since we create the ready promise and, if need resolve it when we create it
(see Animation::GetReady), this patch simply clear the ready promise
when an animation is canceled.
[1] https://w3c.github.io/web-animations/#reset-an-animations-pending-tasks
MozReview-Commit-ID: JxoqeA5dXCO
Before this patch, we store each computed values in a hashtable,
nsRefPtrHashtable<nsUint32HashKey, RawServoAnimationValue>, for all
KeyframeEffectReadOnly on an element, and convert the ServoAnimationValues of
the hashtable into an nsTArray<ServoAnimationValue*> and then convert
the ServoAnimationValues of the nsTArray into PropertyDeclarationBlock
in rust. This way was really inefficient.
In this patch, we store the computed values into AnimationValueMap and
convert all AnimationValue in the map into PropertyDeclarationBlock
after EffectCompositor::GetAnimationRule.
MozReview-Commit-ID: EJ2Kl65fVeF
Later in this patch series we will replace ServoAnimationRule with a hashmap.
At that point, we would like to pass the hashmap to ComposeStyle. In order
to achieve that, this patch templatizes the 'animation rule' parameter of
ComposeStyle in both Animation and KeyframeEffectReadOnly so that it can
represent a hashmap instead.
MozReview-Commit-ID: H5bMxjN3W8n
We will need to remove animation from timeline before calling Animation::UpdateTiming() in order to fire the cancel event.
In bug 1264125, we request one more tick after calling Animation::Cancel(), however we won't need to call this request if we apply this changeset.
MozReview-Commit-ID: h0dxUdtgkl
1. Introduce ServoAnimationRule, which is an equivalent of AnimValuesStyleRule.
2. Wrap ServoAnimationRule and AnimValuesStyleRule into a struct, and
use it as the parameter of Animation::ComposeStyle and
KeyframeEffectReadOnly::ComposeStyle.
3. Uncompute the RawServoAnimationValues in ServoAnimationRule when we
need it.
MozReview-Commit-ID: HahXDYBCAhH
Before this patch we skipped KeyframeEffectReadOnly::ComposeStyle() for
animations that are not in effect.
After this patch we call KeyframeEffectReadOnly::ComposeStyle() even if the
animation is not in-effect state in order to prepare the base style for
properties that can be run on the compositor because the in-effect animation
will be sent to the compositor and might be composed onto the base style on the
compositor after the animation gets out of its delay phase.
MozReview-Commit-ID: FuAZv4jqVMJ
