| Summary: | [iOS] AudioContext is getting suspended when page goes in the background even if navigator.audioSession.type is set to playback | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | youenn fablet <youennf> | ||||||
| Component: | Media | Assignee: | youenn fablet <youennf> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | brad, chrisguttandin, clark1729, craigwharding, javier.velasco86, jblas, judahgabriel, kim, lilrobd1, luming_yin, mattwindwer, me, vikas, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=271178 | ||||||||
| Attachments: |
|
||||||||
|
Description
youenn fablet
2023-09-14 04:06:13 PDT
We probably want the behaviour to match what happens for regular audio elements. Pull request: https://github.com/WebKit/WebKit/pull/17812 Created attachment 469422 [details]
Audio File for Test Case
Added an audio file for a minimal test case that demonstrates the issue.
Created attachment 469423 [details]
Minimal Test Case that Demonstrates the Issue
Attaching a minimal test case that can be used to demonstrate the issue.
We are experiencing this issue within our web app. Calling suspend() and resume() have no affect and triggering play() and pause() dispatches events as expected but timeupdates are never dispatched which I guess is expected since playback is never resumed. I have a music player app that is impacted by this bug. Minimal repro: https://judahtemp.b-cdn.net/ios-webkit-audio-bug/bug.html I just have a single <audio> element in my web app. When the current song ends (via .ended event), I change the audio element src to the new song, and call .play(). This works, unless the page is in the background or the screen is locked. If it is, the .ended event still fires, I can change the .src of the audio and call .play(), but no audio is heard. This bug appears to have been introduced in iOS 17.2.1. It works fine on previous iOS versions, and it works on Android, Mac, and Windows. Is there any update on a resolution to this issue? This issue was first introduced in iOS 17.0 and fixed in iOS 17.1 update. (Reference links below) iOS 17 - 17.1 (Marked as RESOLVED FIXED Sept. 11 2023) AudioContext.createMediaElementSource broken in iOS 17 https://forums.developer.apple.com/forums/thread/740276 HTML5 audio player fails after upgrading iPhone to iOS 17 https://discussions.apple.com/thread/255235567 Bug 261414 - [iOS][GPUP] Allow required syscalls https://bugs.webkit.org/show_bug.cgi?id=261414 PR 17654 with fix included in iOS 17.1 https://github.com/WebKit/WebKit/pull/17654 Then was broken again in iOS 17.2 - 17.3 iOS 17.2.1 (21C66) Broke Audio Streaming from Safari When Not in Focus https://discussions.apple.com/thread/255413652 Please let me know if any additional information is needed. Thank you :) Any updates on the resolution of this issue? I'm suffering from this bug in a web player I'm currently building. Any update? This issue is still present in the latest iOS 17.3.1 update released last week. The current PR needs to address a few more things before being ready. I plan to work on this in the next couple of weeks. Thank you for the update!! (In reply to Kin Blas from comment #6) > We are experiencing this issue within our web app. Calling suspend() and > resume() have no affect and triggering play() and pause() dispatches events > as expected but timeupdates are never dispatched which I guess is expected > since playback is never resumed. I filed https://bugs.webkit.org/show_bug.cgi?id=270352 to keep track of this bug. I am not sure what the actual issue is. Committed 275558@main (b848143a2ad5): <https://commits.webkit.org/275558@main> Reviewed commits have been landed. Closing PR #17812 and removing active labels. Do we know what iOS update this will be apart of? Do we know why this bug keeps coming back into the mix when it was fixed on previous versions? If anyone needs a temporary workaround, you can add another silent audio element to the same page. Both the tag and the referenced audio file need to exist, but the audio doesn't need to be playing: <audio src="silent_audio.mp3" type="audio/mpeg"></audio> After this, next track, back, and forward will work for the main audio element when the browser or web view is suspended. (In reply to Luming Yin from comment #16) > If anyone needs a temporary workaround, you can add another silent audio > element to the same page. Both the tag and the referenced audio file need to > exist, but the audio doesn't need to be playing: > <audio src="silent_audio.mp3" type="audio/mpeg"></audio> > > After this, next track, back, and forward will work for the main audio > element when the browser or web view is suspended. This does not work for me. It creates a second audio player which I don't use, but after the song finishes after Safari doesn't have focus, the song ends and next doesn't play. (In reply to Luming Yin from comment #16) > If anyone needs a temporary workaround, you can add another silent audio > element to the same page. Both the tag and the referenced audio file need to > exist, but the audio doesn't need to be playing: > <audio src="silent_audio.mp3" type="audio/mpeg"></audio> > > After this, next track, back, and forward will work for the main audio > element when the browser or web view is suspended. The workaround didn't seem to work for us either. Do you have a working sample you could show us? The latest iOS update to 17.5 (Apple iPhone) has resolved the issues we were experiencing. Thank you to all teams evolved! Committed 272448.1072@safari-7618-branch (78693e77bdd4): <https://commits.webkit.org/272448.1072@safari-7618-branch> Reviewed commits have been landed. Closing PR #1329 and removing active labels. |