Consider the following workflow: for a particular video device, test a list of standard resolutions for availability, then get a local video stream and display it. This version of the workflow works on iOS 12 (as tested on an iPad Mini 4) and iOS 13 Beta 7 (as tested on an iPhone 7): 1. getUserMedia() 2. enumerateDevices() 3. multiple getUserMedia() in serial to test resolutions 4. getUserMedia() to get and display local video stream. The workflow version above can be seen using this URL: https://staging-connect.circleanywhere.com/public/ios/gum-failure-on-repeat/ However, this slightly different workflow version works on iOS 12 (as tested on an iPad Mini 4), but NOT on iOS 13 Beta (as tested on an iPhone 7): 1. enumerateDevices() 2. getUserMedia() 3. multiple getUserMedia() in serial to test resolutions 4. getUserMedia() to get and display local video stream. The workflow version above can be seen using this URL: https://staging-connect.circleanywhere.com/public/ios/gum-failure-on-repeat/#enumFirst On iOS 13 Beta 7, the first few resolution tests pass, then all the rest and the final getUserMedia() request to display local video fails. I see no reason why the second workflow should fail as it does on iOS 13, so this does seem like a bug. Also, there are other similar complex workflows I've seen that are failing in a similar way on iOS 13, but I've not yet been able to reduce them to a test case.
I wonder whether this is not related to some race conditions we still do not handle well when stopping a track and quickly starting a new capture. We may in fact revoke the sandbox extension too aggressively. One way to confirm this would be to update the test page and stop the tracks at the end of the video checks. Or add a delay between stopping the tracks and restarting a capture.
<rdar://problem/54545538>
This issue still occurs on iOS 13.1.1 on an iPhone 7, and iPadOS 13.1.1 on an iPad Mini. I'm already stopping the tracks at the end of each gUM() request. I wrapped my subsequent calls to resolution tests in setTimeout([test func], 0), and this fixed the error condition. However, this seems like a pretty ugly hack for a hopefully fixable bug.