LayoutTest fast/images/reset-image-animation.html is a flaky failure

• Component: New Bugs
• Status: RESOLVED FIXED

[Ryan Haddad]

LayoutTest fast/images/reset-image-animation.html is a flaky failure

https://build.webkit.org/results/Apple%20Sierra%20Debug%20WK2%20(Tests)/r214472%20(169)/results.html

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fimages%2Freset-image-animation.html

--- /Volumes/Data/slave/sierra-debug-tests-wk2/build/layout-test-results/fast/images/reset-image-animation-expected.txt
+++ /Volumes/Data/slave/sierra-debug-tests-wk2/build/layout-test-results/fast/images/reset-image-animation-actual.txt
@@ -4,7 +4,7 @@
 
 
 PASS internals.imageFrameIndex(image) is 0
-PASS internals.imageFrameIndex(image) is 1
+FAIL internals.imageFrameIndex(image) should be 1. Was 0.
 The animation of the image was reset.
 PASS internals.imageFrameIndex(image) is 0
 PASS internals.imageFrameIndex(image) is 1

[Alexey Proskuryakov]

No clear regression point, but this has become much more frequent about a week ago.

[Alexey Proskuryakov]

Easily reproducible under CPU pressure:

run-webkit-tests -1 -v --no-build fast/images/reset-image-animation.html --repeat-each 1000 -f --child-processes=20

[Alexey Proskuryakov]

r214450 had a fix to make the test not flaky, but it is still flaky.

[Ryan Haddad]

Marked test as flaky in https://trac.webkit.org/r214921

[Fujii Hironori]

WinCairo Debug is the most flaky bot.
https://results.webkit.org/?suite=layout-tests&test=fast%2Fimages%2Freset-image-animation.html

The decoding frame seems to be delayed under heavy CPU load.
The following patch makes the test stable.

diff --git a/LayoutTests/fast/images/reset-image-animation.html b/LayoutTests/fast/images/reset-image-animation.html
index 62cb9bf09894..634a79b7be04 100644
--- a/LayoutTests/fast/images/reset-image-animation.html
+++ b/LayoutTests/fast/images/reset-image-animation.html
@@ -16,7 +16,7 @@
                 shouldBe("internals.imageFrameIndex(image)", expectedFrame.toString());
                 setTimeout(() => {
                     resolve(expectedFrame + 1);
-                }, 30);
+                }, 300);
             });
         }

[Fujii Hironori]

I tried another approach of retrying drawFrame until expected frame without extending the timer duration.
However, I'm observing timeout failure for this approach.
Decoding frame doesn't proceed.
I have to extend the timer duration in this approach too.

diff --git a/LayoutTests/fast/images/reset-image-animation.html b/LayoutTests/fast/images/reset-image-animation.html
index 62cb9bf09894..8c6fdc75ac14 100644
--- a/LayoutTests/fast/images/reset-image-animation.html
+++ b/LayoutTests/fast/images/reset-image-animation.html
@@ -13,6 +13,8 @@
                 let canvas = document.getElementById("canvas");
                 let context = canvas.getContext("2d");
                 context.drawImage(image, 0, 0, canvas.width, canvas.height);
+                if (internals.imageFrameIndex(image) != expectedFrame)
+                    return drawFrame(expectedFrame).then(resolve);
                 shouldBe("internals.imageFrameIndex(image)", expectedFrame.toString());
                 setTimeout(() => {
                     resolve(expectedFrame + 1);

[Fujii Hironori]

Pull request: https://github.com/WebKit/WebKit/pull/13219

[EWS]

Committed 263478@main (b1cc64631025): <https://commits.webkit.org/263478@main>

Reviewed commits have been landed. Closing PR #13219 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/108636160>