haikuwebkit/LayoutTests/animations/animation-direction-normal....

65 lines
2.0 KiB
HTML
Raw Permalink Normal View History

<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
<title>Test of animation-play-state</title>
<style type="text/css" media="screen">
body {
margin: 0;
}
#box {
position: absolute;
left: 0px;
top: 100px;
height: 100px;
width: 100px;
background-color: red;
margin: 0;
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
animation-duration: 500ms;
animation-direction: normal;
animation-iteration-count: infinite;
animation-timing-function: linear;
animation-name: "move1";
}
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
@keyframes move1 {
from { margin-left: 0px; }
to { margin-left: 200px; }
}
</style>
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
<script src="../resources/testharness.js"></script>
<script src="../resources/testharnessreport.js"></script>
<script src="resources/animation-test.js"></script>
</head>
<body>
<div id="box"></div>
<script>
async_test(async t => {
const delay = 100;
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
const test = new AnimationTest({
target: document.getElementById("box"),
styleExtractor: style => parseFloat(style.marginLeft)
});
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
// Record two computed values after the specified delay each.
await test.recordValueAfterRunningFor(delay);
await test.recordValueAfterRunningFor(delay);
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
// We'll now pause the animation using the CSS property "animation-play-state".
box.style.animationPlayState = "paused";
[ Mac iOS ] animations/animation-direction-normal.html is a flaky failure https://bugs.webkit.org/show_bug.cgi?id=210156 <rdar://problem/61411725> Reviewed by Simon Fraser. The tests animations/animation-direction-normal.html and animations/animation-direction-reverse.html were both written similarly to test that an element targeted by a CSS Animation would have styles animated while the animation is running and that those styles would no longer be animated once the CSS Animation was paused using the "animation-play-state" CSS property. The way those assertions were made were to use setTimeout() to check the computed style at a given time and compared it to an expected value give or take an error margin. This design was flaky, as a system under load could easily not run the timeout until a much larger delta than the one expected would elapse. We use a new JS helper to write these tests in a non-flaky manner. The technique used now is to record the computed style while the animation is running without providing expected times and values, but rather specifying delays between which we want to record the computed style. Once all values have been recorded, a method can be used to check those recorded values by using the Web Animations API to pause and seek the animation at recorded times and query the computed style, which allows us to test values without an error margin. Finally, the new JS helper also allows to check the computed style using a timeout when the animation play state is not relevant, allowing those tests to pause the animation using the "animation-play-state" property and check after incremental timeouts that the computed style did not change. We also made the tests use the WPT harness for assertions and reporting. * animations/animation-direction-normal-expected.txt: * animations/animation-direction-normal.html: * animations/animation-direction-reverse-expected.txt: * animations/animation-direction-reverse.html: * animations/resources/animation-test.js: Added. (AnimationTest): (AnimationTest.prototype.get animation): (AnimationTest.prototype.get value): (AnimationTest.prototype.async valueAfterWaitingFor): (AnimationTest.prototype.async recordValueAfterRunningFor): (AnimationTest.prototype.checkRecordedValues): (AnimationTest.prototype._tickUntil): * platform/ios-wk1/TestExpectations: * platform/ios-wk2/TestExpectations: Canonical link: https://commits.webkit.org/223804@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@260577 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-04-23 17:23:18 +00:00
// And now we'll record values after the specified delay each and check that those are the same.
const initialPausedValue = await test.valueAfterWaitingFor(delay);
const currentPausedValue = await test.valueAfterWaitingFor(delay);
assert_equals(initialPausedValue, currentPausedValue, "Values recorded while paused are the same.");
// Finally, check the values recorded earlier in the test.
test.checkRecordedValues();
t.done();
}, `Pausing an animation using the animation-play-state property stops animating styles.`);
</script>
</body>
</html>