[Webkit-unassigned] [Bug 226163] New: SFSafariViewController pauses media playback while in background
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sun May 23 23:31:36 PDT 2021
https://bugs.webkit.org/show_bug.cgi?id=226163
Bug ID: 226163
Summary: SFSafariViewController pauses media playback while in
background
Product: WebKit
Version: Safari 14
Hardware: iPhone / iPad
OS: iOS 14
Status: NEW
Severity: Normal
Priority: P2
Component: New Bugs
Assignee: webkit-unassigned at lists.webkit.org
Reporter: teodor.atroshenko at gmail.com
- User opens an app, which loads a site in SFSafariViewController
- Site makes use of WebRTC, plays remote media in a <video> element, and uses WebSocket for connecting to the control server
- User returns to home screen (aka app with SFSafariViewController goes into background)
- User spends anywhere from seconds to a minute away from the app (e.g., writes a text message, dismisses a notification, rejects an incoming call, takes a photo)
- User returns to the app with SFSafariViewController
Expected:
- Remote streams are playing
- Signaling channel is open
- JS code ran unthrottled in the background
- (Extended goal) If camera/microphone was not used by any other app, their streams have not "ended" while the app is in the background, the behavior currently seen in WKWebView, Safari, or a site open as home screen app.
Actual:
- Remote streams (<video> elements) may be stuck on black screen
- RTCPeerConnections may have been killed
- Signaling (WebSocket) connection is likely killed within ~30 seconds away from the app
- While app was in background, no audio was being played beyond ~1 second after minimizing the app (Control Center shows the site <title> with active playback for 1 second after minimizing, then it clears to "no playback" state)
- Camera and microphone streams have "ended" and new getUserMedia call has to be made
This can also be (partially) reproduced with a simple page playing <audio>. When SFSafariViewController is taken to the background, playback is stopped.
It seems to have always been the case, so no regression here. The behavior is unexpected, however, and requires iOS-specific code for handling (sometimes partially) broken state.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210524/6d79a451/attachment.htm>
More information about the webkit-unassigned
mailing list