[Webkit-unassigned] [Bug 240646] New: AudioContext fails to resume in WKWebView
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu May 19 07:10:48 PDT 2022
https://bugs.webkit.org/show_bug.cgi?id=240646
Bug ID: 240646
Summary: AudioContext fails to resume in WKWebView
Product: WebKit
Version: Safari 15
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: Web Audio
Assignee: webkit-unassigned at lists.webkit.org
Reporter: ashley at scirra.com
CC: cdumez at apple.com
A user of our web-based game engine Construct (www.construct.net) discovered a strange issue with Web Audio in WKWebView. I believe it's a bug in iOS.
Sample Xcode project demonstrating the issue: https://www.dropbox.com/s/5gdoxb9nkcqe9pd/Audio%20test.ios.project.zip?dl=0
This project is built using Cordova and loads some web content in WKWebView. The WKWebView is configured to allow media playback without a user gesture via mediaTypesRequiringUserActionForPlayback, so audio playback immediately on startup is allowed. The web content creates an AudioContext on startup and immediately starts playing a music track.
Press the home button and wait 30 seconds. This fully suspends the app. Then open the app again. It resumes, but there is no audio playback.
I've debugged this and checked:
- the audio context state does return to "running"
- our code correctly remembers where playback reached upon suspending, and re-starts playback upon resuming
- if we add a 5 second delay before starting playback, it works correctly
- if we start playback in a touch (matching the user gesture requirements in the Safari browser), it also works correctly
So it looks like there's a bug in WKWebView where if playback is started immediately, it is not able to continue playback after suspending and resuming.
Perhaps there is a race condition where something needs to happen shortly after audio context creation for suspending/resuming to work? Immediate audio playback is not normally possible in Safari due to the user gesture requirements, so perhaps this is an overlooked aspect of WKWebView.
--
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/20220519/c0d8ca5f/attachment.htm>
More information about the webkit-unassigned
mailing list