media/media-source/media-source-fastseek.html This test is a flaky text failure on wk2 on macOS Monterey and above (EXCEPT on debug builds on x86_64 architecture). HISTORY: https://results.webkit.org/?suite=layout-tests&test=media%2Fmedia-source%2Fmedia-source-fastseek.html&flavor=wk2&version_name=Monterey&version_name=Ventura TEXT DIFF: EXPECTED (video.currentTime.toFixed(1) == '3') OK RUN(video.fastSeek(2)) EVENT(seeked) -EXPECTED (video.currentTime.toFixed(1) == '0') OK +EXPECTED (video.currentTime.toFixed(1) == '0'), OBSERVED '3.0' FAIL END OF TEST DIFF URL: https://build.webkit.org/results/Apple-Ventura-Release-AppleSilicon-WK2-Tests/266873@main%20(4437)/media/media-source/media-source-fastseek-diff.txt REPRODUCTION: I was able to reproduce this bug on macOS Monterey (x86_64) running the test as follows: run-webkit-tests --clobber-old-results --iterations 1000 --exit-after-n-failures 5 media/media-source/media-source-fastseek.html REGRESSION: I was able to bisect a regression point using the flakiness dashboard. This test reproduced at 262173@main, but it did not reproduce at 262172@main. Changes at 262173@main appear to be directly related to this error, and is likely what caused the failure.
<rdar://problem/113881009>
I have marked this test as a flaky failure while the issue is being investigated. (PR link: https://github.com/WebKit/WebKit/pull/16693)
Test gardening commit 266889@main (9544bcf5ae90): <https://commits.webkit.org/266889@main> Reviewed commits have been landed. Closing PR #16693 and removing active labels.
I can see what the problem is: we assume that we have completed the seek when we have a signal that the time changed and that the player is not seeking. However, as soon as the RemoteMediaPlayer receives a timechange call, it assumes seeking has completed. That is not always the case: like if the GPU Process sent timechange just before we started seeking.
fastSeek with MediaSource is broken as it is. When performing an accurate seek, the flow is to call MediaSourcePrivate::waitForSeekCompleted() , seek and then MediaSourcePrivate::seekCompleted(). between the two `waitForSeekCompleted` and `seekCompleted` `MediaPlayerPrivate::seeking` will return false. However, when doing a fast seek, we never call `MediaSourcePrivate::waitForSeekCompleted()` so `MediaPlayerPrivate::seeking` will return a stale value, which is typically the state of the previous seek and so typically `false` In this particular test, when we perform a `fastSeek` , if the GPU Process sent an earlier `timeChanged` as `MediaPlayerPrivate::seeking` will return `false` and so we fire `seeked` event even before the GPU Process has completed the seek operation and had time to update the currentTime to the actual value. I also note that in `void HTMLMediaElement::mediaPlayerTimeChanged()` we immediately call `updateActiveTextTrackCues(currentMediaTime());` but at this stage, currentMediaTime() returns the value of currentTime prior the seek operation. And as such it will set the TrackCues to the wrong time.
It's actually a very similar failure to bug 250844. But while bug 250844 fixed it in just AVFObjC implementation, we can adopt a more global solution by making the entire seek operation an asynchronous operation with completion handlers.
Pull request: https://github.com/WebKit/WebKit/pull/16974
Committed 267279@main (ee5de7a0c1f2): <https://commits.webkit.org/267279@main> Reviewed commits have been landed. Closing PR #16974 and removing active labels.