WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 203435
204261
iOS 13 html audio tag is totally broken: MediaPlayback entitlements error.
https://bugs.webkit.org/show_bug.cgi?id=204261
Summary
iOS 13 html audio tag is totally broken: MediaPlayback entitlements error.
distinctdan
Reported
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.
Attachments
Add attachment
proposed patch, testcase, etc.
distinctdan
Comment 1
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.
Radar WebKit Bug Importer
Comment 2
2019-11-16 15:44:57 PST
<
rdar://problem/57257358
>
Jer Noble
Comment 3
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?
Jer Noble
Comment 4
2019-11-17 16:14:07 PST
Also, what is the session.state value after calling resume() in a user gesture?
Brent Fulgham
Comment 5
2019-11-18 09:12:27 PST
Chris: Is the Process Assertion warning related to
Bug 203633
?
Brent Fulgham
Comment 6
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.
distinctdan
Comment 7
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.
Ashley Gullen
Comment 8
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.
Brent Fulgham
Comment 9
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!
Brent Fulgham
Comment 10
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.
Brent Fulgham
Comment 11
2019-11-20 09:05:42 PST
Sandbox: com.apple.WebKit(36278) deny(1) mach-lookup com.apple.audio.AudioQueueServer
Brent Fulgham
Comment 12
2019-11-20 09:11:02 PST
Confirmed WebContent sandbox is unchanged from 13.0 through 13.2.3.
Ashley Gullen
Comment 13
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.
Ashley Gullen
Comment 14
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.
Per Arne Vollan
Comment 15
2020-01-07 18:15:06 PST
Do you have a Xcode project where the issue can be reproduced?
David Kilzer (:ddkilzer)
Comment 16
2020-01-14 16:56:28 PST
Seems like a dupe of:
Bug 203435
David Kilzer (:ddkilzer)
Comment 17
2020-01-14 16:57:35 PST
*** This bug has been marked as a duplicate of
bug 203435
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug