Bug 215383 – Alternating video/audio stream requests cause stream to permanently fail for tab

• Component: WebRTC
• Status: NEW

[Dustin Greif]

Created attachment 406395 [details]
Reproduction For iPad Safari

We have a web app that uses media streams for a number of features, such as WebRTC and image capture.  We have noticed an issue where media streams become permanently unusable by the current Safari tab on iPads.  I have attached a reproduction of this issue, which will start a video stream, play it, then start an audio stream, then repeat the process.  On the majority of our iPads, this cycle fails after about 80 iterations, but a few don't present the issue.  Sorry the example takes a while to run, our app fails much faster than this but I can't pin down a way to expedite the failure in a minimal reproduction.  A failure presents with the browser providing a video track that is permanently muted.  If you refresh the tab, all video stream requests return a track that is permanently muted and the camera icon in the address bar has a line through it as if permission has been denied.  In that same tab, you can navigate to other web apps that use the camera and they work fine, but if you navigate back to the original domain that failed, you are immediately presented with muted tracks.  If you navigate to the original domain in a new tab, you are able to get video streams again (until the issue presents again).  

Any advice, or a workaround for this issue would be much appreciated.  This is causing major problems for us as we are transition to iPads as the main hardware for our customers.

Known failures on the following setups:
 iPad Pro 12.9 4th Gen (MXAT2LL/A), iOS 13.6
 iPad Pro 12.9 2nd Gen (MP6H2LL/A), iOS 13.4.1
 iPad Pro 11 (MU0T2LL/A), iOS 13.6

[Radar WebKit Bug Importer]

<rdar://problem/66868981>

[youenn fablet]

I reproduced the issue in iOS 13.
I tried on an iPad with a recent iOS 14 build and I did not reproduce it yet.
I saw that sometimes the iteration can take a second or so, but in some other cases, it can take much more than that, especially after about 80 iterations.

[Dustin Greif]

Thanks for taking the time to test it, we really appreciate it!  We just tried the reproduction on 14 beta 8 and it made it to 125 iterations (instead of 80), at which point it was unable to activate the camera.  After one refresh it was still unable to start the camera stream (just showed mic active).  After a second refresh, it started working again (which is improvement over iOS 13 which would never recover in the same tab).

We have been seeing increased rates of these dead streams in iOS 13.6/13.7 as we roll out more iPads, and are narrowing down a way to reproduce the issue quickly.  We will try to pin it down in such a way that we can reproduce it in a few seconds, and will attach the reproduction here when we have it.  Until then, any insight you have as to why the tab is permanently broken and what we can do to avoid this scenario would be much appreciated

[youenn fablet]

(In reply to Dustin Greif from comment #3)
> Thanks for taking the time to test it, we really appreciate it!  We just
> tried the reproduction on 14 beta 8 and it made it to 125 iterations
> (instead of 80), at which point it was unable to activate the camera.

Was it showing the microphone icon?
Have you tried waiting a few minutes?

> We have been seeing increased rates of these dead streams in iOS 13.6/13.7
> as we roll out more iPads, and are narrowing down a way to reproduce the
> issue quickly.

On iOS 14, once the session is started, if WebKit does not grab any frame after some amount of time, it will end the track. Please make sure to check the ended event.

Note also that if you create a lot of video elements, each one of them may keep a captured frame, which might end up being an issue for the camera. You should not count on garbage collection to help you, it is best to reset srcObject to null for instance.

[youenn fablet]

If you can, could you send me a sysdiagnose ([e-mail])?