This assertion is supposed to be used where the first argument has a tolerance
but the second argument doesn't have such tolerance. Whereas
assert_times_equal() is supposed to be used for the case both arguments have
the same tolerance, actually it hasn't, it will be fixed in a subsequent patch
in this patch series.
MozReview-Commit-ID: FEDHilbX2rm
As mentioned in the previous commit, with the conformant Promise handling there
are cases where a requestAnimationFrame callback can happen in the same tick of
the refresh driver, that is, the same animation frame. We should only count
callbacks that occur in frames subsequent to the current one.
MozReview-Commit-ID: IEC7uFwGysS
With the conformant Promise handling, there are cases that we are still in the
same tick even after we got a reqeustAnimationFrame. For example, if we call
requestAnimationFrame() in the callback for an animationstart event, the
callback is processed just before the callback for requestAnimationFrame is
processed in a tick, so we are still in the same tick even after we got the
requestAnimationFrame.
MozReview-Commit-ID: Cgnu7Mk4Nl8
When paintingSuppressed flag is true, paint_listener.waitForPaints() defers the
waiting paint to the next tick. The paintingSupressed flag is set when pres
shell is initialized and at that time if the document has not been loaded yet,
a timer is created to clear the flag after nglayout.initialpaint.delay
elapsed. And when the timer is fired, the flag is cleared, but if there is
still pending reflow, it's not cleared.
So what happened in the failure case;
1) In the first promise_test we wait for document load
2) The paintingSuppressed flag is set in the first promise_test and create the
timer
3) When the document has been loaded but the timer has not yet been fired,
start test refresh mode and create an element in the subsequent promise_test
4) Creating the element triggers a reflow
5) waitForPaints() is called
6) The timer is fired, but there is a pending reflow, so skip clearing the flag
7) Now it's in the test refresh mode, the pending flow will never be processed
until some triggers happen (i.e. mouse movement, calling
advanceTimeAndRefresh, etc.)
8) The test is timed out
MozReview-Commit-ID: 5fLn9SNHp1J
DOMWindowUtils.isStyledByServo checks not only the preference value but also
STYLO_FORCE_ENABLED value. This is important especially when we run test on
our CI. On our CI, the preference value is false but just STYLO_FORCE_ENABLED
is set.
MozReview-Commit-ID: FKEd5LFwcxf
Once upon a time[1] a test was added to test_deferred_start.html to test the
code path where we establish the start time to pass to the compositor when
resolving a pending animation.
Later[2], however, we encountered intermittent failures on B2G so we made it
stop waiting on animation.ready and use waitForPaints instead. There were two
problems with this, however.
Firstly, waiting for paints often means that extra paints are processed such
that we end up updating the start time on the layer using a different code path
and masking any potential bugs in the code path under test.
Secondly, when we made this change we replaced:
return animation.ready.then(function() { /* test code */ })
with:
return waitForPaints(function() { /* test code */ })
And sadly that means that 'test code' never runs. Of course, what we meant to
write was:
return waitForPaints().then(function() { /* test code */ })
As a result, when we later broke the code path under test no one noticed.
This patch restores the test so that it tests what it intends to (and currently
fails, at least most of the time).
[1] https://hg.mozilla.org/mozilla-central/rev/79cac8c71159
[2] https://hg.mozilla.org/mozilla-central/rev/986b18fdfdba
[3] https://hg.mozilla.org/mozilla-central/rev/b66b75c2d042101b954e6423438cc07955c2b9bd
MozReview-Commit-ID: 1iMWLQP6zae
This function is only used in test_animation_observers_sync.html. Putting it in
another file makes test_animation_observers_sync.html harder to follow so until
we actually share it with other files we should be it in the one file.
MozReview-Commit-ID: DJXWH4wFWxZ
window.requestIdleCallback can not be used right after enabling its pref in the
same window object. We need to open a new window after enabling the pref.
Also, setting layout.css.devPixelsPerPx in the new windows seems to make
test_session_scroll_position.html failure on Android, so in this patch
setting layout.css.devPixelsPerPx is set before opening the new window.
"general.useragent.locale" too.
This patca moves waitForIdleCallback from testcommon.js for preventing from
being used in other tests unintentionally.
MozReview-Commit-ID: Erm2BPnikvB
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
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().
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).
