Bug 221359 – [ Mac WK2 ] compositing/animation/keyframe-order.html is a flakey image failure

• Component: New Bugs
• Status: RESOLVED FIXED

[Robert Jenner]

compositing/animation/keyframe-order.html

Is a Flakey image failure on MacOS in WK2.

HISTORY URL:
compositing/animation/keyframe-order.html

DIFF URL(s):
https://build.webkit.org/results/Apple-BigSur-Release-WK2-Tests/r271592%20(1023)/compositing/animation/keyframe-order-diff.png
https://build.webkit.org/results/Apple-Catalina-Debug-WK2-Tests/r271660%20(8657)/compositing/animation/keyframe-order-diff.png
https://build.webkit.org/results/Apple-BigSur-Release-WK2-Tests/r271698%20(1082)/compositing/animation/keyframe-order-diff.png
https://build.webkit.org/results/Apple-Catalina-Release-WK2-Tests/r271930%20(11356)/compositing/animation/keyframe-order-diff.png
https://build.webkit.org/results/Apple-BigSur-Release-WK2-Tests/r272317%20(1391)/compositing/animation/keyframe-order-diff.png
https://build.webkit.org/results/Apple-BigSur-Release-WK2-Tests/r272338%20(1401)/compositing/animation/keyframe-order-diff.png


Was not able to reproduce, as it's very flakey. However, every time a failure has been reported, it is the same image failure at Image Diff 1.49%

First reported failure was at Changeset:

https://trac.webkit.org/changeset/271592/webkit

Uncertain if that caused the failure, but that's where history reports it as starting.

[Robert Jenner]

Pasted incorrect history url. 

HISTORY URL:
https://results.webkit.org/?suite=layout-tests&test=compositing%2Fanimation%2Fkeyframe-order.html&platform=mac

[Radar WebKit Bug Importer]

<rdar://problem/73951735>

[Truitt Savell]

I was able to reproduce this using command on tip of tree:

run-webkit-tests --iterations 2000 --exit-after-n-failures 1 --exit-after-n-crashes-or-timeouts 1 --debug-rwt-logging --no-retry --force --no-build -f --root /Volumes/Data/tmp/MacRelease compositing/animation/keyframe-order.html

[Robert Jenner]

Created attachment 423236 [details]
Diff Images from Image Failing test

Attaching DIFF images from flakey image failing test.

[Antoine Quint]

Last two failures were April 2 and March 18.

[Antoine Quint]

I can reproduce locally:

rwt --debug --iterations=10000 --force --exit-after-n-failures=1 --no-build compositing/animation/keyframe-order.html

[Antoine Quint]

Created attachment 425501 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 425501 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=425501&action=review

> LayoutTests/compositing/animation/keyframe-order.html:57
> +                await UIHelper.ensurePresentationUpdate();

I think renderingUpdate() would be more appropriate.

[Dean Jackson]

Comment on attachment 425501 [details]
Patch

r+ but listen to smfr

[Antoine Quint]

(In reply to Simon Fraser (smfr) from comment #8)
> Comment on attachment 425501 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=425501&action=review
> 
> > LayoutTests/compositing/animation/keyframe-order.html:57
> > +                await UIHelper.ensurePresentationUpdate();
> 
> I think renderingUpdate() would be more appropriate.

I don't think it is actually, at least in my experience this will just ensure that animations have been updated in the Web Animations sense, but not that accelerated animations will have been committed.

I will try that route though to check.

[Simon Fraser (smfr)]

Go look at the implementations of doAfterPresentationUpdate(). They only do anything related to rendering on iOS.

[Antoine Quint]

Created attachment 425596 [details]
Patch for landing

[Antoine Quint]

animation.ready + UIHelper.renderingUpdate() seem to improve things. Let's see the effect on the bots.

[Antoine Quint]

Created attachment 425600 [details]
Patch for landing

[EWS]

Committed r275752 (236330@main): <https://commits.webkit.org/236330@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 425600 [details].