Bug 1484901 - Add tolerance for time comparison in playing-an-animation.html; r=hiro This test appears to occasionally fail. The suspected cause is a combination of: * timer clamping (due to vsync) resulting in the current timeline time after resuming playback and the "ready time" being equal * difference in floating-point precision used in calculating the two measures -- one calculation done in JS and one done using the UA's internal representation of times. Therefore this patch adds the standard tolerance for comparing time values to this comparison. Differential Revision: https://phabricator.services.mozilla.com/D3857

Bug 1484148 - Make CSSTransition startTime test timeout when waiting for transition events after a fixed number of frames; r=hiro See bug 1467344 comment 34. Differential Revision: https://phabricator.services.mozilla.com/D3753

Bug 1484148 - Add a test for resuming from paused; r=hiro As bug 1467344 comment 40, it appears we don't currently have any tests that cover resuming a paused animation. Differential Revision: https://phabricator.services.mozilla.com/D3752

Bug 1467344 - Update corresponding tests for CSS animations to make them consistent; r=hiro This is a collection of fix-ups to the corresponding tests for CSS animations to apply the same sort of naming etc. that we have now applied to CSS transitions tests.

Bug 1467344 - Update event-dispatch test now that we can use the updated EventWatcher; r=hiro

Bug 1467344 - Add spec links to test files; r=hiro

Bug 1467344 - Move tests from dom/animations/tests/css-transitions to WPT; r=hiro

Bug 1467344 - Drop use of flushComputedStyle in css-transitions tests; r=hiro flushComputedStyle is as follows: var cs = getComputedStyle(elem); cs.marginLeft; That _probably_ flushes style in most engines, but it's possible some engine in the future will optimize things in a way that it can flush marginLeft without flushing, say, backgroundColor. Before moving these tests to wpt, it would be better to explicitly flush the property (or at least one of the properties) we are transitioning. This patch also updates the "Setting zero combined duration" test from test_animation-cancel.html since, in making this change, I realized the test was wrong. Specifically, it was testing that when we set a combined duration of zero that a transition is canceled. However, nothing in the spec requires this. The spec only requires a non-zero combined duration to _start_ a transition and only cancels an existing transition if the combined duration becomes _zero_ if the "the end value of the running transition is not equal to the value of the property in the after-change style". This test passed, however, because it changed the transition property to margin-top, hence it was actually testing the same condition as the previous test.

Bug 1467344 - Update tests in test_setting-effect.html; r=hiro This patch splits the first test into four separate tests since it really seems to be testing four different things. Likewise, the later patch for replacing the effect is split into two parts: - One to test the playState behavior - One to test the value reported by transitionProperty The test, "After setting a transition's effect to null, transitionend is still dispatched", is dropped since it is covered by the last test in test_event-dispatch.html.

Bug 1467344 - Update tests in test_keyframeeffect-getkeyframes.html; r=hiro This patch merely tidies up some whitespace and uses of quotes / template strings. There are no substantive changes.

Bug 1467344 - Update tests in test_animation-element-get-animations.html; r=hiro This mostly just tidies up these tests to give them sensible titles. The only test with major substantive changes is the first test. This test tests three things: 1) That getAnimations() returns one transition per transitioning property 2) That getAnimations() returns transitions in the order they were generated 3) That CSS transitions have their start time set based on when they were generated. (2) is covered later in this file by the test: 'getAnimations sorts transitions by when they were generated' (3) is really a test for startTime, if anything, not getAnimations(). I'm not sure how necessary it is, but I've added it to test_animation-starttime.html for now. As a result, this patch updates this first test to only cover (1).

Bug 1467344 - Tidy up test in test_csstransition-transitionproperty.html; r=hiro This is mostly whitespace tidy-ups. The only substantive change is the fix to the test description which previously seemed to be missing some words.

Bug 1467344 - Update tests in test_animation-starttime.html; r=hiro Apart from obvious tidy-ups the substantive changes to tests in this file are as follows: * Skipping forward through animation -> This is really testing two things: (a) That you can seek a transition using the start time. (b) That seeking a transition using the start time triggers dispatching events. This patch splits the above into two separate tests. * Skipping backwards through animation, -> All these tests are really just exercising event dispatch which is already covered by test_event-dispatch.html. As a result this patch drops these tests. * Setting startTime to null -> Covered by 'Setting an unresolved start time sets the hold time' in wpt/web-animations/timing-model/animations/setting-the-start-time-of-an-animation.html * Animation.startTime after pausing -> Covered by 'Pausing clears the start time' in wpt/web-animations/timing-model/animations/pausing-an-animation.html

Bug 1467344 - Update tests in test_animation-ready.html; r=hiro The test: 'A new ready promise is created each time play() is called the animation property', is covered in: web-animations/interfaces/Animation/ready.html by the 'A new ready promise is created when play()/pause() is called' test. As a result, this patch removes that test.

Bug 1467344 - Drop test_animation-pausing.html; r=hiro This seems to be adequately covered by: web-animations/timing-model/animations/pausing-an-animation.html (specifically the last test: 'The animation's current time remains fixed after pausing') web-animations/timing-model/animation-effects/simple-iteration-progress.html (which checks that the iteration progress is correctly calculated from the current time)

Bug 1467344 - Update tests in test_animation-finished.html; r=hiro For the first test, we really want to check that it is possible to restart transitions (since they are otherwise disassociated once they finish) hence this patch updates the test to the actual output in style rather than timing. The second test is covered in web-animations/timing-model/animations/reversing-an-animation.html by the 'Playing a finished and reversed animation seeks to end' test so this patch removes it from this file.

Bug 1467344 - Update tests in test_animation-currenttime.html; r=hiro This patch basically completely rewrites this file to make it simpler and remove unnecessary tests. In particular: * It sets the duration and delay to 100s to match what we use in most tests * All the helper methods at the start are inlined into the relevant tests because doing so makes the tests much easier to read and debug. * The first two tests are combined and extended - Testing the initial current time is zero is not generally useful but it is when we're testing setting it - What the second test really wants to test is that the style updates (i.e. you really can seek a transition, not just that the currentTime value updates) - The trick where we set the start time just to get out of the pending state seems unnecessary, we may as well just wait on ready. In fact, we don't _need_ to do that, but this test is about checking you can seek a transition in motion. * In the fourth test, 'Skipping backwards through transition', we don't check the event is dispatched since that is covered in test_event-dispatch.html in the 'Active -> Before' test. * The final test, 'Animation.currentTime after pausing', is covered by web-animations/timing-model/animations/pausing-an-animation.html

Bug 1467344 - Fix some minor formatting in test_animation-computed-timing.html; r=hiro

Bug 1467344 - Drop some unnecessary <body> elements from test files; r=hiro We're a bit inconsistent about this, but generally we try to keep this files as minimal as possible. There is still a lot of other cruft in the starttime and currenttime test files but we will remove that when we tidy up those files in later patches in this series.

Bug 1467344 - Update the titles of each test file; r=hiro

Bug 1467344 - Fix the spelling of canceled/canceling in dom/animation/test/css-transitions/; r=hiro

Bug 1467344 - Replace var with const/let in dom/animation/test/css-transitions/; r=hiro

Bug 1467344 - Use async/await in dom/animation/test/css-transitions/; r=hiro As part of this change, the "Restart transition after cancelling transition immediately" test in test_event-dispatch.html needed significant changes. The reason is that this test was calling: watcher.wait_for([ 'transitioncancel', 'transitionrun', 'transitionstart' ]); However, it was not waiting for the result of that call and hence was not actually checking if the events were being dispatched. And, they are not. There are two problems. Firstly, this test cancels the transition by setting display:none. However, transitions don't run on display:none elements so attempting to restart the transition will not generate transition events. This might be a bug, but it is not a recent regression in any case (I tested back to Firefox 54). However, this test does not require using display:none to cancel. There are _many_ tests that check that display:none generates a transitioncancel event. This test only needs to make the transition idle. As a result, this patch makes that test call transition.cancel() instead. However, even with that change this test will not pass because it sets a transition-delay of 100s (presumably so that it does not need to check for a transitionstart event). As a result this test should not wait on _both_ transitionrun and transitionstart but just transitionrun.

Bug 1467344 - Use arrow functions in dom/animation/test/css-transitions/; r=hiro This patch also drops the checkStateOnSettingCurrentTimeToZero function since it is no longer used.

Bug 1479681: Fix the loop in nsTransitionManager dealing with stopping `all` transitions. r=hiro The loop was mutating the nsCSSPropertyID used to guard the exit, which is obviously wrong. This branch is pretty rarely taken, since people don't usually specify `all` as a transition property other than the first, for which case we take the fast path with `checkProperties = false`. Our test-suite failed to catch this. Added a crashtest that hangs without this patch. The reason bug 1478990 regressed this is because it changed the order of nsCSSPropertyID so that `p` actually went backwards causing the infinite loop, but the bug was introduced (by me, whoops) in bug 1309752. Differential Revision: https://phabricator.services.mozilla.com/D2552 MozReview-Commit-ID: Ii3D1FaZ31R

Bug 1479681: Fix the loop in nsTransitionManager dealing with stopping `all` transitions. r=hiro a=aryx The loop was mutating the nsCSSPropertyID used to guard the exit, which is obviously wrong. This branch is pretty rarely taken, since people don't usually specify `all` as a transition property other than the first, for which case we take the fast path with `checkProperties = false`. Our test-suite failed to catch this. Added a crashtest that hangs without this patch. The reason bug 1478990 regressed this is because it changed the order of nsCSSPropertyID so that `p` actually went backwards causing the infinite loop, but the bug was introduced (by me, whoops) in bug 1309752. Differential Revision: https://phabricator.services.mozilla.com/D2552 MozReview-Commit-ID: Ii3D1FaZ31R

Bug 1479234 - Include missing headers in D3D11YCbCrImage.cpp and VRLayerChild.cpp. r=hiro MozReview-Commit-ID: C8VQO46Lm1

Bug 1479234 - Include missing headers in D3D11YCbCrImage.cpp and VRLayerChild.cpp. r?hiro MozReview-Commit-ID: C8VQO46Lm1

Bug 1479239: prefers-reduced-motion should be sensible re. unsupported platforms / resistFingerprinting. r=hiro With the current early-returning behavior, the expression will unconditionally evaluate to false, which is a bit of a footgun. Make sure to always return no-preference in unsupported platforms or when resisting fingerprinting. Differential Revision: https://phabricator.services.mozilla.com/D2491 MozReview-Commit-ID: 41uUudut7b4

Bug 1479230: Remove useless condition in GetPrefersReducedMotion. r=hiro This query is always enabled in content, so this check is always true. Differential Revision: https://phabricator.services.mozilla.com/D2490 MozReview-Commit-ID: 5etk5TM0agz

Bug 1478213 - Don't ignore a redundant change to setting the animation start time if we are pending; r=hiro As discussed here: https://github.com/w3c/csswg-drafts/issues/2691 We have a similar check in SetCurrentTime (with the exception that, according to the spec, this behavior applies to either play OR pause pending, instead of just pause-pending) so this patch tries to match the comment and format of that check. Differential Revision: https://phabricator.services.mozilla.com/D2410

Bug 1478213 - Add test that fails if we ignore a seemingly redundant setting of startTime to null; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D2409

Bug 1477486 - Add dom.animations-api.getAnimations.enabled pref to css-logical test suite; r=hiro In particular the animation-003 test needs it but we may as well turn it on for all tests since we'll possibly add more tests like this in the future.

Bug 1477486 - Fix typo in animation-003.tenative.html filename; r=hiro

Bug 1477486 - Add dom.animations-api.getAnimations.enabled pref to css-logical test suite; r?hiro In particular the animation-003 test needs it but we may as well turn it on for all tests since we'll possibly add more tests like this in the future. MozReview-Commit-ID: FaRgJkV2jUs

Bug 1477486 - Fix typo in animation-003.tenative.html filename; r?hiro MozReview-Commit-ID: 5LgZTUqVtKH

Bug 1471814 - Add a preference for {Document,Element}.getAnimations(); r=bz,hiro This is probably the last thing we will ship since it needs the most spec work. MozReview-Commit-ID: LLmDBLCsCBJ

Bug 1471814 - Ignore the composite member on Keyframe objects when the compositing pref is not set; r=hiro MozReview-Commit-ID: 9Xn32jLlpq1

Bug 1471814 - Add a preference for animation composite modes; r=bz,hiro This feature should not be shipped until the various definitions of addition for each additive property are properly specified. Unlike other patches in this series, compositing is not frequently used internally (e.g. by DevTools etc.) so there is no need to enable this by default for system code. Also, it turns out we have inadvertently been shipping part of this feature for some time now. The next patch in this series will add tests for that case and disable that part of the feature (a suitable intent to unship will follow). This patch merely adapts and extends the existing tests without affecting the surface area covered by the combination of the newly-added pref and the existing dom.animations-api.core.enabled pref. MozReview-Commit-ID: Htr6mlyCBav

Bug 1471814 - Add a preference for implicit keyframes; r=bz,hiro This preference controls whether authors are allowed to specify animations without a 0% or 100% keyframe. We intend to ship this soon but this preference acts as a safeguard in case we discover we need to disable it. This feature is very convenient and commonly used so this patch ensures it is always enabled for system content. MozReview-Commit-ID: BHTsuS2xO61

Bug 1471814 - Add a preference for Web Animations timelines; r=bz,hiro We don't intend to ship this in the near future until the integration with AnimationWorklet is clear (although we might ship a read-only version). That said, we use this feature extensively internally (e.g. in DevTools etc.) so we enable this feature for system callers. MozReview-Commit-ID: AhB7ZmU1Xzw

Bug 1471814 - Add a preference for {Document,Element}.getAnimations(); r?hiro, r?bz This is probably the last thing we will ship since it needs the most spec work. MozReview-Commit-ID: LLmDBLCsCBJ

Bug 1471814 - Ignore the composite member on Keyframe objects when the compositing pref is not set; r?hiro MozReview-Commit-ID: 9Xn32jLlpq1

Bug 1471814 - Add a preference for animation composite modes; r?hiro, r?bz This feature should not be shipped until the various definitions of addition for each additive property are properly specified. Unlike other patches in this series, compositing is not frequently used internally (e.g. by DevTools etc.) so there is no need to enable this by default for system code. Also, it turns out we have inadvertently been shipping part of this feature for some time now. The next patch in this series will add tests for that case and disable that part of the feature (a suitable intent to unship will follow). This patch merely adapts and extends the existing tests without affecting the surface area covered by the combination of the newly-added pref and the existing dom.animations-api.core.enabled pref. MozReview-Commit-ID: Htr6mlyCBav

Bug 1471814 - Add a preference for implicit keyframes; r?hiro r?bz This preference controls whether authors are allowed to specify animations without a 0% or 100% keyframe. We intend to ship this soon but this preference acts as a safeguard in case we discover we need to disable it. This feature is very convenient and commonly used so this patch ensures it is always enabled for system content. MozReview-Commit-ID: BHTsuS2xO61

Bug 1471814 - Add a preference for Web Animations timelines; r?hiro, r?bz We don't intend to ship this in the near future until the integration with AnimationWorklet is clear (although we might ship a read-only version). That said, we use this feature extensively internally (e.g. in DevTools etc.) so we enable this feature for system callers. MozReview-Commit-ID: AhB7ZmU1Xzw

Bug 1471814 - Add a preference for {Document,Element}.getAnimations(); r?hiro, r?bz This is probably the last thing we will ship since it needs the most spec work. MozReview-Commit-ID: LLmDBLCsCBJ

Bug 1471814 - Ignore the composite member on Keyframe objects when the compositing pref is not set; r?hiro MozReview-Commit-ID: 9Xn32jLlpq1

Bug 1471814 - Add a preference for animation composite modes; r?hiro, r?bz This feature should not be shipped until the various definitions of addition for each additive property are properly specified. Unlike other patches in this series, compositing is not frequently used internally (e.g. by DevTools etc.) so there is no need to enable this by default for system code. Also, it turns out we have inadvertently been shipping part of this feature for some time now. The next patch in this series will add tests for that case and disable that part of the feature (a suitable intent to unship will follow). This patch merely adapts and extends the existing tests without affecting the surface area covered by the combination of the newly-added pref and the existing dom.animations-api.core.enabled pref. MozReview-Commit-ID: Htr6mlyCBav

Bug 1471814 - Add a preference for {Document,Element}.getAnimations(); r?hiro, r?bz This is probably the last thing we will ship since it needs the most spec work. MozReview-Commit-ID: LLmDBLCsCBJ