There were two places run gAnimationsTests in
test_animation_performance_warning.html.
MozReview-Commit-ID: zrD5eMiDsy
--HG--
extra : rebase_source : 250f826daed4440725c0a28fdb1fcd84fd299402
Currently isRunningOnCompositor flag is not cleared when 'display:none'
is set to the target element.
We need to fix it at some point.
MozReview-Commit-ID: CjtWUyT9CP9
--HG--
extra : rebase_source : c1da5ed5e79f9a7f78d920943dabad719cb7abc7
In promise chains, we don't have to use t.step_func. However, when there
are callbacks in promise chains, assertions in the callbacks need wrapped
in either t.step or t.step_func.
If we use t.step_func, a variable scope might be divided. This can be a
problem when an assertion uses local-scope variable (e.g. the callback
in MutationObserver uses an assertion which take `changedAnimation`).
Therefore, t.step is helpful in this case.
(There no t.step_func we should remove in web-platform tests.)
MozReview-Commit-ID: IiSizgCQjpG
--HG--
extra : rebase_source : bfe314c20763d0ea26127dd561c64388d6431bf3
Previously, every test and support file would be synced to the objdir
when running any test. Now that only those support files and tests requested
are synced, we note support files required beyond those in a test's
directory in ini manifests.
MozReview-Commit-ID: EmlDz9d4lqt
In some of these cases, this increase isn't strictly necessary, because we only
check state immediately after creating the animation, before it could have
completed (regardless of its duration). Still: we should consistently use long
durations for any animations that aren't expected to complete during the test
run, because short durations might accidentally get copypasted into new tests
where they might cause intermittent failures.
MozReview-Commit-ID: 8wSRqHMI12L
--HG--
extra : rebase_source : 12e6a054dce047351b06e064bcedd9cdec58150f
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
--HG--
extra : rebase_source : 5acf081fb844f81280765a87ec019b7847ca1885
Add tests in test_animation_observers.html, so we can test elements and pseudo
elements together by setting subtree.
--HG--
extra : rebase_source : 1841d5db93657a07772bc73ce99cb6ab2a43a737
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
--HG--
extra : rebase_source : 14e5412015b6c2c7ec6b7e105d414a89fc746c77
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
--HG--
extra : rebase_source : 714fdf85484775244daad6aaa288b1ec73ad6793
The type name has been changed and re-ordered.
MozReview-Commit-ID: 78jrJ6a9Pro
--HG--
extra : rebase_source : f47e6bf27d8e48d10b3af123308c2ab89e71d8e1
Those message will be modified in part 4 (localization).
MozReview-Commit-ID: 6TMUxemVLcu
--HG--
extra : rebase_source : 65ef1879b3e606ae6dc279981b1e995c7b2cd40b
Now we produce computed timing progress outside [0,1] range.
We use the last segment to calculate animation values if the value is greater than 1.
We use the first segment to calculate animation values if the value is lesser than 0.
We don't need observe restylings other than animations. If those restylings
happen, it's just noise for this test. We should drop them.
--HG--
extra : transplant_source : 9%0B%0B%B7O%E5R%86%D4%7F%29%90q%DDQ0%0B%FAuJ
Before this fix, sometimes an element which was removed in a prior test
would still visible when subsequent test starts.
We should wait for paints to complete after the element has been removed.
--HG--
extra : transplant_source : %C7%7F%03%0F%DA%05A%C1%CE%F0m%DA1%C5%1D%FA%06%FA%FE%CA
In current our implemantation, animations which can run on compositor
in invisible element can not run on compositor on all desktop platforms.
*BUT* both on Android and B2G the animations still run on compositor somehow.
And one more thing. Animations can run on compositor in elements which are
scrolled out in the parent element *RUN* on compositor as well.
mochitest does not allow us to disable each test on specific platforms respectively.
One we have mozinfo in mochitest (bug 1150818), we can skip the tests on specific platforms.
Since part 3 in this patch series updated the way we clear the "running on
compositor" flag, we can update these tests so they no longer wait for this
flag (see bug 1226118 comment 21).
Fix: INFO TEST-UNEXPECTED-FAIL | dom/animation/test/chrome/test_animation_observers.html | Test timed out.
By extending animation observer timeout.
--HG--
extra : commitid : GEfsdBOqqsu
The Animation.pause() method operates asynchronously since, if the animation is
currently running on the compositor, we should wait for the animation to stop
on the compositor before establishing the pause time. Otherwise, if the
compositor is ahead of the main thread and we use the main thread's notion of
the current time to establish the pause time, the animation will jump backwards
when we take it off the compositor.
This pause time is represented using the "hold time".
However, when we have a finished animation, its current time is not advancing
but rather its current time is fixed to its end time. This too is represented
using the hold time. As a result, if we pause a finished animation we should
not update its hold time (by calculating the current time from the start time)
but just continue to use the existing hold time. This is true of any other
situation where we might have set the hold time before or during pausing.
Animation::Tick contains special handling to cope with pending ready times
that are in the future. This was originally introduced to cope with the
situation where we are called multiple times per refresh-driver tick.
As of bug 1195180, Animation::Tick should no longer be called multiple
times per refresh driver tick. It would seem, therefore, that we no longer
need to check for a future time. However, since introducing this check, the
vsync refresh driver timer has been added which means that we can still have
a recorded time from TimeStamp::Now that is ahead of the vsync time used to
update the refresh driver. In that case, however, rather than waiting for the
next tick, we should simply clamp that pending ready time to the refresh driver
time and finish pending immediately.
This patch also updates one of the tests for reversing. With this updated
behavior we can sometimes arrive at a situation where when an Animation starts
and its ready promise resolves, its currentTime is still 0. If we call
reverse() at this point on an animation with an infinite active duration it
should throw an InvalidStateError. To avoid this situation, this test makes
sure we wait an extra frame before calling reverse().
This patch adds a test that even when we seek from being irrelevant to another
state where we no longer need ticks that we still spin the refresh driver
in order to queue and dispatch an animationstart event.
Having created composite ordering methods for the different kinds of animations
this patch adds a Comparator class so that they can be used to sort an
array of such animations.
This patch uses this Comparator object to sort the results returned by
Element.getAnimations. For this case, the order in which we create animations
and transitions happens to almost perfectly correspond with the composite
ordering defined so that no sorting is necessary.
One exception is that some -moz-* transitions may be created after transitions
that they should sort before when sorting by transition property. In this
case the sorting added in this patch should ensure they are returned in the
correct sequence.
Unfortunately, we can't easily test this since the test files we have are
intended to be cross-browser (where -moz-* properties won't be supported).
Once we implement AnimationTimeline.getAnimations (bug 1150810) we'll have
a better opportunity to test this sorting. For now, the added tests in this
patch just serve as a regression test that the sorting hasn't upset the
already correct order (and an interop test in future once we move them to
web-platform-tests).
--HG--
extra : commitid : KkfoSE69B0F
extra : rebase_source : ee4e47f44281504eb4d35e0f6cc3392ee0cffb94
This patch also extends the tests for Element.getAnimations(). It doesn't
actually exercise the code added (it's not actually called yet since it doesn't
need to be for Element.getAnimations) but simply provides a useful regression
and interop test.
--HG--
extra : commitid : KWpAsc2Aj54
extra : rebase_source : abe26dc3d79a50239c62dd156dc0a0aa29c11d52
We have already resolved to make calling Finish() clear the pause state (see
https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0038.html, item 2).
Doing that involves resolving the start time when the animation is paused.
Furthermore, as a separate change, we resolved to make the finished promise not
resolve when the animation is paused. That suggests making UpdateFinishedState()
only resolve the finished promise when PlayState() == Finished rather than using
IsFinished() which returns true even if the animation is paused.
However, if we compare PlayState() == Finished in UpdateFinishedState() then we
will *not* resolve the finished promise when the animation is play-pending since
PlayState() == Pending in that case (pause-pending is ok since the call to
SetCurrentTime will cause a transition to the Paused state). Furthermore, the
existing call to cancel the pending play task will effectively leave this
animation forever pending. Hence, in this patch we unconditionally fill in the
start time.
--HG--
extra : rebase_source : 499ad0530eac0ee62c8ed2df41360c45abc34816
The point of making pausing async is to allow time to sync up the current time
with the compositor. Setting the current time manually should simply force it to
the specified time and complete the pause action, not abort it. (We do a similar
thing for a pending play. For a pending play we're waiting to establish
a suitable start time. Manually setting the start time in that case simply
forces the start time to the specified time and completes the play operation.)
--HG--
extra : rebase_source : 614ed9ef01204e4137783c0d48e975eb8febbe2a
Animation::ResumeAt contains an assertion that, when we exit the play-pending
state, checks we either have a resolved start time or a resolved hold time.
That's normally true but if we are aborting a pause on animation that is
finished we can end up with a resolved start time (since we don't clear the
start time when we're aborting a pause) and a resolved hold time (either
because the regular finishing behavior set one, or, because play() applied
auto-rewinding behavior and set it).
In that case we should actually respect the hold time and update the start time
when resuming the animation. However, ResumeAt won't update the start time if it
is already set.
This patch fixes that by clearing the start time in DoPlay in the case where we
are aborting a pause and have a hold time.
--HG--
extra : rebase_source : 83f980d6cbc34375274f30f6527992b4fec7f639
There are still some other references to "source" in AnimationPlayer such as
HasInPlayerSource and UpdateSourceContent. These are renamed in a subsequent
patch (that doesn'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.
--HG--
rename : dom/animation/Animation.cpp => dom/animation/KeyframeEffect.cpp
rename : dom/animation/Animation.h => dom/animation/KeyframeEffect.h
rename : dom/animation/test/css-animations/test_animation-name.html => dom/animation/test/css-animations/test_effect-name.html
rename : dom/animation/test/css-animations/test_animation-target.html => dom/animation/test/css-animations/test_effect-target.html
rename : dom/animation/test/css-transitions/test_animation-name.html => dom/animation/test/css-transitions/test_effect-name.html
rename : dom/animation/test/css-transitions/test_animation-target.html => dom/animation/test/css-transitions/test_effect-target.html
rename : dom/webidl/Animation.webidl => dom/webidl/KeyframeEffect.webidl
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.
--HG--
rename : dom/animation/test/css-animations/test_animation-effect-name.html => dom/animation/test/css-animations/test_animation-name.html
rename : dom/animation/test/css-transitions/test_animation-effect-name.html => dom/animation/test/css-transitions/test_animation-name.html
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.
The tests in dom/animation/tests/ use an old version of idlharness.js that
doesn't support inherited interfaces. As discussed in bug 1152619 we're not
looking at updating these old tests (under dom/imptests) at the moment which
means we won't be able to update the IDL tests in dom/animation/tests/ to
continue passing once we introduce DocumentTimeline as a subinterface of
AnimationTimeline.
As a result, this patch simply the removes the IDL tests for this interface from
dom/animation/tests. However, we have a test for this interface in
web-platform-tests where I've set up a pull request to apply the required
renaming so we should eventually get test coverage for this renaming.
https://github.com/w3c/web-platform-tests/pull/1748
In the long run, all the tests in dom/animation/tests should end up in
web-platform-tests. The main reason they aren't there yet is that most of them
test the mapping between the Web Animations API and CSS and there's currently no
spec defining that so there's no place to put them in the web-platform-tests
repository.
There are a few tests for animation timeline which could be landed in
web-platform-tests (and then removed from dom/animation/tests) but we need to
discuss with Google if this is the desired behavior or not first. For the time
being I have a branch setup for that and I'm leaving the tests in
dom/animation/tests so we continue to test what *we* think the behavior should
be in the meantime. That branch is here:
https://github.com/birtles/web-platform-tests/compare/rename-animation-timeline...birtles:add-hidden-iframe-tests
This patch (finally) puts pausing animations in the pending player map so that
they are resolved asynchronously.
Since this changes the pausing behavior this patch updates a number of tests so
that they continue to pass.
A number of animation tests assume that pausing happens instantaneously. This
patch adjust many of those tests so that they will continue to work when
pausing happens asynchronously. In many cases this is possible because we
know the ready promise on AnimationPlayer (soon to be Animation) objects will
be resolved so we can wait on it and it will resolve immediately now, but when
asynchronous pausing is introduced the test the promise won't resolve until
after the pause operation is complete.
There are some tests that can't be so easily adjusted and we will have to fix
these at the same time as we turn on async pausing. However, taking care of
this set of tests now should reduce the size of subsequent patches in this
series.
Now that we have separate tests for checking the initial state of startTime we
can remove these checks from tests for setting the startTime.
Also, while we're at it, we needn't check the playState and animationPlayState
since these should be covered by other tests.
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.
Hiroyuki Ikezoe
Boris Chiou
Brian Birtles
Mantaroh Yoshinaga
Carsten "Tomcat" Book
Daisuke Akatsuka
Ryo Kato
Chris Manchester
emi suzuki
Rob McAuley
Ryo Motozawa
Cameron McCormack
Shirotaka_Pro
N.Shimizu
Randall Barker
Jonathan Watt
Boris Zbarsky
Wes Kocher
L. David Baron
Mason Chang
Jonathan Griffin
David Zbarsky
Alexandre Poirot