Bug 305712 – REGRESSION (iOS 26.2): ManagedMediaSource Cold Start Failure

• Status: NEW
• Component: Media

On iOS 26 Safari, the first ManagedMediaSource instance created after a browser cold start fails when performing simultaneous appendBuffer() calls to multiple SourceBuffers. The readyState property incorrectly reports "open" but the SourceBuffer error indicates the MediaSource is in "ended" state.


REPRODUCTION

Live demo: https://zalishchuk.github.io/ios-26-mms-bug/
Source code: https://github.com/zalishchuk/ios-26-mms-bug

Steps to Reproduce:
1. Force-close Safari from the app switcher (swipe up to kill)
2. Reopen Safari
3. Navigate to https://zalishchuk.github.io/ios-26-mms-bug/
4. The "simultaneous" test runs automatically and fails

Expected: Both appendBuffer() calls complete successfully with updateend events.

Actual: One or both SourceBuffers emit an error event. The error indicates MediaSource readyState is "ended", but checking mediaSource.readyState returns "open".


KEY OBSERVATIONS

1. Only affects first MMS: Reloading the page works. Creating a second ManagedMediaSource works. Only the very first instance after cold start is affected.
2. readyState lies: mediaSource.readyState returns "open" but the error message says "ended".
3. No sourceended event: The sourceended event is never fired before the error.
4. Sequential appends work: If you append to one SourceBuffer, wait for updateend, then append to the second, it works.
5. Single SourceBuffer works: Creating only one SourceBuffer and appending works fine.


ENVIRONMENT

- iOS 26 Safari
- Affects ManagedMediaSource only (not regular MediaSource)


POSSIBLY RELATED

Safari 26 release notes mention: "Added support for detachable MediaSource objects to allow for seamless switching between objects attached to a media element. (129298010)"

The bug may be related to lazy initialization of the ManagedMediaSource subsystem introduced with this feature.

POTENTIALLY RELATED COMMITS

1. Detachable MediaSource (Sept 2024)

   Commit: 2ee9927bd954263ac537fd27463d167c87de05e3
   Bug: https://bugs.webkit.org/show_bug.cgi?id=279875
   Radar: rdar://129298010 (matches Safari 26 release notes)

   Major changes:
   - 77 files modified
   - Refactored onReadyStateChange() method
   - Changed setReadyState call from:
       onReadyStateChange(oldState, state);
     to:
       onReadyStateChange(oldState, readyState());

   This change queries readyState() again instead of using the intended state parameter, potentially introducing a race condition if the state changes between set and query.


2. Work Queue for MediaSourcePrivate (Feb 2024)

   Commit: 90086fffd11
   Bug: https://bugs.webkit.org/show_bug.cgi?id=265982

   Introduced dedicated work queue for MediaSourcePrivateRemote and SourceBufferPrivateRemote.


3. Dedicated Work Queue (Nov 2025)

   Commit: 27f78b632f8
   Bug: https://bugs.webkit.org/show_bug.cgi?id=302054

   Added dedicated work queues for MediaSourcePrivate and SourceBufferPrivate.


4. ReadyState Reference Point Change (Nov 2025)

   Commit: ae8698d30174d73c3c7da72a642fc42b74ad46ae
   Bug: https://bugs.webkit.org/show_bug.cgi?id=302242
   Radar: rdar://164381937

   Changed MediaSourcePrivate to be the reference point for readyState value.

   Key change: The notification to the player is asynchronous via ensureOnMainThread, which could cause race conditions.


HYPOTHESIS

On cold start:

1. Browser's work queue / dispatcher infrastructure isn't fully initialized
2. First ManagedMediaSource is created
3. open() sets m_openDeferred = true and schedules async callbacks
4. Two SourceBuffers are created
5. Simultaneous appendBuffer() calls queue operations on shared work queue
6. Due to incomplete initialization, internal state transitions race
7. State briefly becomes "ended" (or is read as "ended" due to sync issues)
8. SourceBuffer error fires with readyState: "ended"
9. But sourceended event never dispatches (transient state or event lost)
10. Subsequent MMS instances work because infrastructure is now initialized

Additional investigation findings from iOS system logs (Console.app) and targeted tests:

TEST RESULTS
============

Test 1: Concurrent appends (1 MMS, 2 SourceBuffers)
- Append to both SBs simultaneously
- Result: One fails with ParsingFailed

Test 2: Sequential appends (1 MMS, 2 SourceBuffers)
- Append to SB1, wait for completion, then append to SB2
- Result: Both succeed

Test 3: Two MMS attempts (1 MMS, 2 SourceBuffers each)
- First MMS with concurrent appends fails
- Create second MMS, concurrent appends succeed
- Result: First fails, second succeeds

Test 4: Two separate MMS (2 video elements, 1 SB each)
- Two completely separate MMS instances
- Each has only 1 SourceBuffer
- Append to both simultaneously
- Result: One fails with ParsingFailed

Test 5: Two MMS, single append (2 video elements, 1 SB each)
- Create both MMS with SourceBuffers
- Only append to first MMS
- Result: Succeeds

FINDINGS
========

1. The race is specifically triggered by concurrent appendBuffer calls
   - Creating multiple MMS/SourceBuffers without appending is fine (Test 5)

2. Sequential appends work even on cold start (Test 2)

3. The race is NOT specific to SourceBuffers within a single MMS
   - Two completely separate MMS instances with 1 SB each still race (Test 4)

4. It's not deterministic which request fails
   - Sometimes SB1/MMS1 fails, sometimes SB2/MMS2 fails

5. Second/subsequent attempts work
   - Once initialization completes, concurrent appends succeed

IOS SYSTEM LOGS
===============

Observed in Console.app during cold start failure:

- mediaparserd connection activates during append operations
- mediaparserd logs: "FigApplicationStateMonitor signalled err=-19431"
- However, this error also appears in successful sequential test
- So -19431 is NOT the direct cause

Timeline (concurrent test - fails):
  +0ms    appendBuffer(SB1)
  +0ms    appendBuffer(SB2)
  +1ms    mediaparserd connection activating
  +11ms   SB1 completes OK
  +11ms   SB2 fails: ParsingFailed
  +11ms   MediaSource state -> ended

Timeline (sequential test - succeeds):
  +0ms    appendBuffer(SB1)
  +5ms    mediaparserd connection activating
  +12ms   mediaparserd err=-19431 (still happens!)
  +17ms   SB1 completes OK
  +17ms   appendBuffer(SB2)
  +18ms   SB2 completes OK

CONCLUSION
==========

Concurrent appendBuffer calls during cold start trigger a race condition at some shared layer between MMS instances. The race appears to be in iOS media parsing infrastructure (we observe mediaparserd in logs) but we cannot definitively identify the exact location.

Additional findings on affected iOS versions:

AFFECTED:
- Real physical iPhone devices with iOS 26.2 - consistently reproduces (tested on multiple different devices)

NOT AFFECTED:
- iOS 26.0 on real physical devices
- iOS 26.1 on real physical devices
- iOS 26.2 on Xcode Simulator

This suggests the bug was introduced specifically in iOS 26.2 and only manifests on real hardware, not in the simulator environment.

[Alexey Proskuryakov]

Thank you for the report! I confirmed that this fails on iOS 26.2, and works on iOS 26.

However, this appears to be already fixed in a newer WebKit build that I have on my device. The CC'ed folks would know more about this.

That's great news, thank you for confirming!

If possible, I'd be curious to know what the root cause was. I invested quite a bit of time debugging this and got as far as observing mediaparserd initialization correlating with the failure, but couldn't pinpoint the exact issue.

If the fix isn't related to internal/private Apple code and you're able to share what was happening, I'd really appreciate knowing, mostly out of curiosity and to learn from it. Thanks!