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.
Pasted incorrect history url. HISTORY URL: https://results.webkit.org/?suite=layout-tests&test=compositing%2Fanimation%2Fkeyframe-order.html&platform=mac
<rdar://problem/73951735>
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
Created attachment 423236 [details] Diff Images from Image Failing test Attaching DIFF images from flakey image failing test.
Last two failures were April 2 and March 18.
I can reproduce locally: rwt --debug --iterations=10000 --force --exit-after-n-failures=1 --no-build compositing/animation/keyframe-order.html
Created attachment 425501 [details] Patch
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.
Comment on attachment 425501 [details] Patch r+ but listen to smfr
(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.
Go look at the implementations of doAfterPresentationUpdate(). They only do anything related to rendering on iOS.
Created attachment 425596 [details] Patch for landing
animation.ready + UIHelper.renderingUpdate() seem to improve things. Let's see the effect on the bots.
Created attachment 425600 [details] Patch for landing
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].