We removed access to the Audio Processing Tap XPC service in our iOS 13 work because our testing did not show it being used in normal browsing tests. Unfortunately, it is used in some web audio cases (and games). This patch makes two changes: (1) It restores access to the "com.apple.coremedia.audioprocessingtap.xpc" XPC service. (2) It checks the return value of MTAudioProcessingTapCreate (which fails when the service is blocked) and returns early to avoid using the invalid audio tap.
<rdar://problem/51565203>
Created attachment 374622 [details] Patch
*** Bug 200012 has been marked as a duplicate of this bug. ***
Comment on attachment 374622 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=374622&action=review R=me. > Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb:380 > + (global-name "com.apple.coremedia.audioprocessingtap.xpc") ;; <rdar://problem/51565203> I think the explicit allow in not needed, since it is already allowed in the imported sandbox file. > Source/WebKit/WebProcess/com.apple.WebProcess.sb.in:609 > + (global-name "com.apple.coremedia.audioprocessingtap.xpc") ;; <rdar://problem/51565203> Is this needed on macOS?
Created attachment 374631 [details] Patch for landing
Created attachment 374632 [details] Patch for landing
Comment on attachment 374632 [details] Patch for landing Clearing flags on attachment: 374632 Committed r247701: <https://trac.webkit.org/changeset/247701>
All reviewed patches have been landed. Closing bug.