Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: da06d39f11c38563a494e6a66e34a1964612a7aa
https://github.com/WebKit/WebKit/commit/da06d39f11c38563a494e6a66e34a1964612a7aa
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-08-26 (Wed, 26 Aug 2026)
Changed paths:
A
LayoutTests/media/video-interruption-play-restores-playing-state-expected.txt
A LayoutTests/media/video-interruption-play-restores-playing-state.html
M Source/WebCore/platform/audio/MediaSessionManagerInterface.cpp
M Source/WebCore/platform/audio/PlatformMediaSession.cpp
Log Message:
-----------
(319455@main) Multiple YouTube videos can play simultaneously across separate
Safari windows
https://bugs.webkit.org/show_bug.cgi?id=322558
rdar://185734791
Reviewed by Youenn Fablet.
319455@main turned clientWillBeginPlayback() from a completion-handler API
into one returning GenericPromise, and serialized admissions on
m_currentPlaybackAdmission
so they always completed in request order.
Starting a video asks the media session manager for permission to play. Once
granted, the session claims the Playing state.
That claim is what pauses videos in other windows and tells the UI process
which video is playing.
In one case the claim was refused. The check guarding it compared the session's
state at the end of the request against its state at the start, and read a
change to Paused as a pause()
arriving in the meantime.
That was right for every starting state but one: a session already Playing
never made a request, a session already Paused had not changed state, and a
session
that started out Autoplaying or Idle and ended up Paused really had been paused.
A session that started out as Interrupted was the exception.
Granting its request ended the interruption, and ending an interruption put the
session back to the state it held when the
interruption began (Paused), for a video another window had just paused.
So the check fired on a change the request had made itself. The session claimed
nothing, the UI process was never
told, the video in the other window kept playing, and both played at once.
endInterruption() now restores Playing whenever a play request is in flight,
whatever the session was doing when the interruption began. beginInterruption()
already did this for a request
already in flight; this covers one that started later.
Neither the stale restored state nor the check itself is new (319455@main only
moved the check into commitPlaybackAdmission()).
What made it visible was gating enforceConcurrentPlaybackRestriction() and the
notification to the UI process on the check's result.
Before, both ran either way, so a session that failed to claim Playing still
paused the others.
Test: media/video-interruption-play-restores-playing-state.html
*
LayoutTests/media/video-interruption-play-restores-playing-state-expected.txt:
Added.
* LayoutTests/media/video-interruption-play-restores-playing-state.html: Added.
* Source/WebCore/platform/audio/MediaSessionManagerInterface.cpp:
(WebCore::MediaSessionManagerInterface::startSessionAdmission):
* Source/WebCore/platform/audio/PlatformMediaSession.cpp:
(WebCore::PlatformMediaSession::endInterruption):
Canonical link: https://commits.webkit.org/319859@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
