We rename the file_XXX contents to test_XXX_to_rename so that these tests keep
running (so long as they begin with file_ and not test_ the test harness will
refuse to run them). If we rename these files to test_XXX in the same patch
Mercurial will not treat this as a rename and so we will lose the history
associated with file_XXX.
Instead, we rename test_XXX_to_rename to test_XXX in the next patch in this
series and by doing this Mercurial will treat this as two rename operations and
`hg log -f test_XXX` will show the history file_XXX as well.
One minor exception to this occurs due to the fact that we have two naming
conventions:
(a) For tests in css-animations, css-transitions, style etc.
Most of these tests should eventually land in web-platform-tests. However,
in many cases that's not yet possible because, for example, CSS
Animations 2 does not yet specify the behavior tested by the
css-animations tests.
For tests in web-platform-tests we generally separate words using -.
However, our mochitest running machinery requires that tests begin with
test_. Hence we name tests: test_abc-def-ghi.html.
(b) For tests in mozilla
These tests are never intended to be part of web-platform-tests and
generally for mochitests we use _ to separate words (hence the test_
prefix). Hence we name these tests test_abc_def_ghi.html
Now, there are some tests in the 'mozilla' directory that use the (a) naming
scheme instead of (b). In this case, instead of renaming file_xxx-xxx.html to
test_xxx-xxx_to_rename.html in this patch, and then renaming
test_xxx-xxx_to_rename.html to test_xxx-xxx.html in a second patch, we can just
delete test_xxx-xxx.html and rename file_xxx-xxx.html to test_xxx_xxx.html in
the one patch and Mercurial will recognize this as a rename because the file
names don't overlap.
MozReview-Commit-ID: Etcdmyfx0zf
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
It is possible that animating computed style becomes the same value as the
value in the previous tick if Animation.mPendingReadyTime is pretty close
to the timeline current time.
MozReview-Commit-ID: COuur4Wlufx
This change is the same as bug 1422995. With the conformant Promise handling
and performing micro task checkpoint in Animation tick, waitForFrame() inside
the callback for Animation.ready does not make sure that the next frame happens.
MozReview-Commit-ID: KEz4xmHpGlk
We clamp animation start time on the second restyling when the initial paint
for the animation took over vsync refresh rate (16.6ms normally as of today).
The clamping leads the animation progress to the same value as the initial one.
Once this clamping happens, the animation value does not change even after
waiting for Animation.ready and a reqeustAnimationFrame. To make the animation
value change happen we should wait for one more requestAnimationFrame.
MozReview-Commit-ID: 8OTC0xkKBrr
I modified several tests which related animationstart event delay.
animation-starttime and animation-currenttime tests:
- Moved the getComputedStyle tests to test/style.
- Removed the animation.playState tests. This tests contained by playState tests of web-platform-tests.
- Lining common function. (e.g. calculating current/start time. etc)
MozReview-Commit-ID: 9kD9ZR1KxGv
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
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).
