Bug 204261

Summary: iOS 13 html audio tag is totally broken: MediaPlayback entitlements error.
Product: WebKit Reporter: distinctdan
Component: Web AudioAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Critical CC: ashley, bfulgham, brian+webkitbugzilla, cdumez, ddkilzer, eric.carlson, jer.noble, pvollan, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: Safari 13   
Hardware: iPhone / iPad   
OS: iOS 13   

Description distinctdan 2019-11-15 16:12:31 PST
I have a cordova game running a wkwebview on iPadOS 13.2.2 and I'm trying to play an html audio element that's connected to an AudioContext. However, the audio never plays at all. No javascript errors are thrown, and everything appears perfectly happy from the js side. I'm not trying to do background audio, this is just normal foreground audio. Here's the native error that's thrown:


2019-11-15 18:27:09.610800-0500 Orbus[9045:99562] [assertion] Error acquiring assertion: <NSError: 0x2811ddfe0; domain: RBSAssertionErrorDomain; code: 2; reason: "Client is missing required entitlement"> {
    userInfo = {
        RBSAssertionAttribute = <RBSLegacyAttribute: 0x111048cf0; requestedReason: MediaPlayback; reason: MediaPlayback; flags: PreventTaskSuspend | PreventTaskThrottleDown | WantsForegroundResourcePriority>;
    }
}
2019-11-15 18:27:09.610840-0500 Orbus[9045:99562] [ProcessSuspension]  0x108ee7138 - ProcessAssertion() PID 9045 Unable to acquire assertion for process with PID 9045
2019-11-15 18:27:09.610894-0500 Orbus[9045:99269] [ProcessSuspension] 0x108ee7138 - ProcessAssertion::processAssertionWasInvalidated()


My code checks for the state of the audio context and waits for a user interaction if necessary (which shouldn't be necessary in a webview anyways), but iOS tells the js that everything is fine. This used to work fine in iOS 12. Also, weirdly enough, the audio does play in an iPadOs 13.2.2 simulator even though the error is still thrown. However, when running on an identical real device, it doesn't play. Seems like just regular old audio playing shouldn't require any sort of special entitlement. Music is an important part of my app, so this is a pretty big deal to me. Any workarounds would also be welcome.
Comment 1 distinctdan 2019-11-15 19:19:34 PST
Also, I tried setting the "Audio, AirPlay, and Picture in Picture" and "Background processing" flags in the Background Modes tab of xcode, but it didn't help.
Comment 2 Radar WebKit Bug Importer 2019-11-16 15:44:57 PST
<rdar://problem/57257358>
Comment 3 Jer Noble 2019-11-17 16:12:55 PST
I know this is going to sound ridiculous, but we have to check the most basic problems first. WebAudio plays at the “ambient” audio session category. Which means it’s affected by the hardware mute switch. Can you verify that the mute switch in your test device is off?
Comment 4 Jer Noble 2019-11-17 16:14:07 PST
Also, what is the session.state value after calling resume() in a user gesture?
Comment 5 Brent Fulgham 2019-11-18 09:12:27 PST
Chris: Is the Process Assertion warning related to Bug 203633?
Comment 6 Brent Fulgham 2019-11-18 09:14:01 PST
Would it be possible to capture a sysdiagnose on the failing device? I wonder if you are hitting a sandbox violation that could explain the change in behavior? It's hard to tell without access to a logging.

You can open an Apple bug report if you are uncomfortable attaching a sysdiagnose to this Open Source bug.
Comment 7 distinctdan 2019-11-18 17:14:06 PST
Sure thing, so I'm testing on an iPad Pro 3rd gen, which doesn't have a hardware mute switch, and I've made sure the volume is turned on. 

The audio context actually starts in a state of "running". I've tried calling resume on it anyways after a user gesture, but it doesn't make any difference. After I try playing my audio, the context state is still "running". Also, the promise returned from calling "myAudio.play()" resolves, just like it's a success. The html Audio element's "paused" property is also false, like it believes that it actually is playing. When running in a simulator, the audio does play, so I know my nodes are connected correctly.

I forgot to mention, I can play audio successfully through the same context using BufferSourceNodes. However, these are only suitable for very short sounds, so I'm unable to use them for playing longer things like background music.

@Brent - Yeah, I'd rather not post a sysdiagnose here, but I just ran one after reproing the error and submitted it in on the Feedback Assistant portal. In the description, I referenced this issue and referenced the log lines where the error occurs.
Comment 8 Ashley Gullen 2019-11-20 08:59:18 PST
This is also affecting all Construct 3 (www.construct.net) content published to iOS. A user has reported it to us here: https://github.com/Scirra/Construct-3-bugs/issues/3477

This is going to be really painful for us if this update goes out to everybody.

Our testing indicates iOS 13.1 was not affected, suggesting this is a regression in iOS 13.2 that still affects the latest iOS 13.2.3.
Comment 9 Brent Fulgham 2019-11-20 09:02:11 PST
(In reply to distinctdan from comment #7)
> @Brent - Yeah, I'd rather not post a sysdiagnose here, but I just ran one
> after reproing the error and submitted it in on the Feedback Assistant
> portal. In the description, I referenced this issue and referenced the log
> lines where the error occurs.

For the record: This ended up being <rdar://problem/57303963>.

Thank you for taking the time to file that!
Comment 10 Brent Fulgham 2019-11-20 09:05:34 PST
Could be due to a sandbox violation, though I don't recall us changing this between 13.1 and 13.2.3.
Comment 11 Brent Fulgham 2019-11-20 09:05:42 PST
Sandbox: com.apple.WebKit(36278) deny(1) mach-lookup com.apple.audio.AudioQueueServer
Comment 12 Brent Fulgham 2019-11-20 09:11:02 PST
Confirmed WebContent sandbox is unchanged from 13.0 through 13.2.3.
Comment 13 Ashley Gullen 2019-11-20 09:46:27 PST
I'd add that in our case (for Construct-made content), we only ever use the Web Audio API and never use the <audio> tag, and it still seems to be affected in the same way as described in this issue. So it suggests it affects all audio playback regardless of the API.
Comment 14 Ashley Gullen 2019-11-29 02:36:53 PST
From our investigation it looks like setting silent mode on the device now blocks WKWebView, whereas normal web pages (and some other apps) can continue to play sound. This inconsistency appears to have caused the confusion here where it seems like WKWebView can't play sound.

I'm not sure what the intended behavior is for this but it could well be an unintentional regression.
Comment 15 Per Arne Vollan 2020-01-07 18:15:06 PST
Do you have a Xcode project where the issue can be reproduced?
Comment 16 David Kilzer (:ddkilzer) 2020-01-14 16:56:28 PST
Seems like a dupe of:  Bug 203435
Comment 17 David Kilzer (:ddkilzer) 2020-01-14 16:57:35 PST

*** This bug has been marked as a duplicate of bug 203435 ***