Bug 260185 – REGRESSION(262173@main): media/media-source/media-source-fastseek.html is a flaky text failure

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Ben Schwartz]

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.

[Radar WebKit Bug Importer]

<rdar://problem/113881009>

[Ben Schwartz]

I have marked this test as a flaky failure while the issue is being investigated. (PR link: https://github.com/WebKit/WebKit/pull/16693)

[EWS]

Test gardening commit 266889@main (9544bcf5ae90): <https://commits.webkit.org/266889@main>

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

[Jean-Yves Avenard [:jya]]

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.

[Jean-Yves Avenard [:jya]]

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.

[Jean-Yves Avenard [:jya]]

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.

[Jean-Yves Avenard [:jya]]

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

[EWS]

Committed 267279@main (ee5de7a0c1f2): <https://commits.webkit.org/267279@main>

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