In this patch series we adjust the behavior of animation starting so that the
animation does not actually start until the following refresh driver tick. This
requires some tweaks to tests to ensure they continue to pass.
This patch adds a test that we correctly incorporate the delay when setting
a layer animation's initialCurrentTime.
The notion of 'current time' on layer animations differs from that on main
thread animations in that it does not incorporate the animation delay.
Instead, we wait until an animation's delay has complete before putting it
on the layer and then it we add without delay.
For animations that are still waiting to start we need to factor this delay into
the initialCurrentTime stored on the layer animation so that when we update
the animation's start time it represents the time *after* the delay has
finished. Previously we failed to do this but no tests failed since all existing
tests for delay rely on DOMWindowUtils.advanceTimeAndRefresh which avoids this
particular code path (since we don't add pending animations to layers while
the refresh driver is under test control).
This patch adds a test for animation delay that does not rely on
DOMWindowUtils.advanceTimeAndRefresh which has been confirmed to fail if we
don't incorporate the delay in our calculation of initialCurrentTime.
This patch (finally!) introduces the delayed start behavior. It updates
AnimationPlayer::DoPlay to put animations in the PendingPlayerTracker from
where they are triggered.
This patch also updates nsTransitionManager to set the animation's source
before calling Play as otherwise the AnimationPlayer won't be able to access
the pending player tracker (which it locates by navigating AnimationPlayer ->
Animation (source content) -> target element -> composed doc -> pending player
tracker). In future, when we support setting the AnimationPlayer.source property
we will make this more robust so that the order in which these steps are
performed doesn't matter.
This patch also updates a couple of tests to reflect the fact that
AnimationPlayer will now return the pending state.
This patch adds a test that we correctly incorporate the delay when setting
a layer animation's initialCurrentTime.
The notion of 'current time' on layer animations differs from that on main
thread animations in that it does not incorporate the animation delay.
Instead, we wait until an animation's delay has complete before putting it
on the layer and then it we add without delay.
For animations that are still waiting to start we need to factor this delay into
the initialCurrentTime stored on the layer animation so that when we update
the animation's start time it represents the time *after* the delay has
finished. Previously we failed to do this but no tests failed since all existing
tests for delay rely on DOMWindowUtils.advanceTimeAndRefresh which avoids this
particular code path (since we don't add pending animations to layers while
the refresh driver is under test control).
This patch adds a test for animation delay that does not rely on
DOMWindowUtils.advanceTimeAndRefresh which has been confirmed to fail if we
don't incorporate the delay in our calculation of initialCurrentTime.
This patch (finally!) introduces the delayed start behavior. It updates
AnimationPlayer::DoPlay to put animations in the PendingPlayerTracker from
where they are triggered.
This patch also updates nsTransitionManager to set the animation's source
before calling Play as otherwise the AnimationPlayer won't be able to access
the pending player tracker (which it locates by navigating AnimationPlayer ->
Animation (source content) -> target element -> composed doc -> pending player
tracker). In future, when we support setting the AnimationPlayer.source property
we will make this more robust so that the order in which these steps are
performed doesn't matter.
This patch also updates a couple of tests to reflect the fact that
AnimationPlayer will now return the pending state.
AnimationPlayer.ready will currently always be resolved but by updating these
tests to wait on it anyway they should continue to work once we introduce the
delayed animation start behavior.
Since bug 1104433, step_func now passes on the return value of its callback.
That means we can use it directly as a Promise callback function in Promise
chains where the return value of the function is another Promise.
This patch updates existing tests to eliminate the awkward handling we had
around wrapping some parts of Promise callbacks in step() but leaving the return
statement outside it.
This patch moves commonly used addDiv and waitForFrame test methods to
a separate testcommon.js support file.
It also takes advantage of the updates to testharness.js from bug 1104433 to
rework addDiv such that it automatically removes the created div at the end of
the test.
This patch makes Element::GetAnimationPlayers return not only current animations
but also animations that have finished but are filling forwards. This brings the
implementation into line with recent changes to the Web Animations spec and
allows querying all the animations that are currently affecting an element or
which are scheduled to do so in the future.
A document that belongs to an iframe that is display:none as no associated pres
context from which to get a refresh driver. However, in this case
document.timeline.currentTime should still never go backwards (since document
timelines are supposed to be monotonically increasing).
This patch makes AnimationTimeline record the last value returned for the
current time so that if the document becomes display:none we can still return
the most recently used time.
This patch changes the order in which we look for matches when updating existing
animations. Previously we would iterate through new animations in a forwards
direction but match old animations by going through the list of animations
backwards.
This patch makes us iterate through both lists in a backwards direction. That
means that if we have:
animation: anim 100s
and later we make it
animation: anim 100s, anim 100s
Then the new animation will be added to the *start* of the list, i.e. prepended,
and the resulting animation will not restart.
Previously when updating animations we'd generate a new list of animation
objects then try to match up animations from the existing list and copy across
state such as start times and notification flags. However, this means that from
the API we end up returning different objects.
This patch makes us maintain the same object identity when updating an existing
animation. It does this by looking for matching animations in both lists. If it
finds a match it copies the necessary information from the *new* animation to
the *existing* animation (but preserving the start time, last notification
etc.). Then, finally, it puts the *existing* animation in the list of *new*
animations and removes the corresponding *new* animation. The existing
animation is also removed from the list of existing animations so that it only
matches once.
The method used for matching is probably not intuitive but this is addressed in
a subsequent patch in this series.
Brian Birtles
David Zbarsky
Alexandre Poirot
Jonathan Griffin