Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 4775179da61b9e0a4da8fbd2e02638cfdcbb12fd
https://github.com/WebKit/WebKit/commit/4775179da61b9e0a4da8fbd2e02638cfdcbb12fd
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-04-07 (Tue, 07 Apr 2026)
Changed paths:
M
LayoutTests/http/wpt/mediarecorder/MediaRecorder-audio-samplingrate-change.html
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
Log Message:
-----------
[macOS iOS]
http/wpt/mediarecorder/MediaRecorder-audio-samplingrate-change.html is flaky
https://bugs.webkit.org/show_bug.cgi?id=311378
rdar://173975629
Reviewed by Eric Carlson.
In 309373@main, the WebM player was made to run in parallel by no longer
operating
on the main thread.
As a consequence, some operations happen faster than it used to, such as reading
the media's init segment.
Prior 309373@main, the readyState would have moved past HAVE_METADATA only once
all the samples had been demuxed and playback start would have been delayed
until then.
Following the changes, the main thread is no longer blocked while waiting on all
the samples to be read, and so occasionally, the duration wouldn't be known
at the time the readyState had progressed.
We need to wait for the durationchange event before the duration is guaranteed
to be valid.
Re-enabling test.
*
LayoutTests/http/wpt/mediarecorder/MediaRecorder-audio-samplingrate-change.html:
* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
Canonical link: https://commits.webkit.org/310758@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
