313098 2026-04-22 21:39:22 -0700 media/media-source/media-managedmse-resume-after-stall.html is an intermittent failure 2026-04-24 17:53:37 -0700 1 1 1 Unclassified WebKit Media WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 jean-yves.avenard jean-yves.avenard webkit-bug-importer oldest_to_newest 2203522 0 jean-yves.avenard 2026-04-22 21:39:22 -0700 Times out from time to time. 2203523 1 webkit-bug-importer 2026-04-22 21:39:28 -0700 <rdar://problem/175395328> 2203527 2 jean-yves.avenard 2026-04-22 22:17:16 -0700 can be reproduced locally with `run-webkit-tests --release --no-retry --repeat=50 --exit-after-n-crashes-or-timeouts=1 media/media-source/media-managedmse-resume-after-stall.html` [4/50] media/media-source/media-managedmse-resume-after-stall.html failed unexpectedly (test timed out, text diff) Exiting early after 0 crashes and 1 timeouts. 4 tests run. 2 tests ran as expected, 2 didn't (46 didn't run): Unexpected flakiness: timeouts (1) media/media-source/media-managedmse-resume-after-stall.html [ Pass Timeout ] 2203572 3 jean-yves.avenard 2026-04-23 01:06:38 -0700 This is a regression from the MediaContainment feature. What's happening is that when we re-enqueue samples on the SourceBuffer, we override samples. This cause the renderer's tracks to be flushed. When new samples have been re-appended and the buffered range no longer have a gap, we call AudioVideoRenderer::play() on the main thread. Samples are enqueued by the SourceBufferPrivate on the MediaSourcePrivate's queue. If the play() command runs first, setting the rate on the synchroniser before any audio samples being re-enqueued: setRate appears to fail and is a de-facto no-op. Once audio is appended, playback never resume. 2203921 4 jean-yves.avenard 2026-04-23 15:57:48 -0700 Analysis above ended up not being the cause. In this test the interaction with the renderer should be as followed: play() -> stall() -> flush() -> enqueueSamples() -> play() from time to time it becomes: play() -> stall() -> play() -> flush() -> enqueueSamples() When this happens, and play() is called while the synchroniser and audio/video renderer have been suspended me make it resume, this makes the synchroniser time to stop progressing, the flush / enqueue doesn't resume things. This is a race between the MediaSource calling play() on the main thread and the SourceBufferPrivate performing the flush/re-enqueue on its queue. The order of operations is no longer deterministic when it used to be (everything was on the main thread before) 2203932 5 jean-yves.avenard 2026-04-23 16:27:20 -0700 Pull request: https://github.com/WebKit/WebKit/pull/63480 2204340 6 ews-feeder 2026-04-24 17:53:35 -0700 Committed 311992@main (09ea5e2ced87): <https://commits.webkit.org/311992@main> Reviewed commits have been landed. Closing PR #63480 and removing active labels.