Bug 204106 – Calling getUserMedia multiple times in same tab can cause NotReadableError

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebRTC

[Dag-Inge Aas]

Created attachment 383343 [details]
Screenshot showing the issue on an iPhone X running iOS 13.2

Summary:
Calling getUserMedia multiple times on the same page (after stopping the tracks of the original getUserMedia stream) can cause getUserMedia to fail with NotReadableError. After this the tab is broken for further usages of getUserMedia and Safari must be restarted to fix the issue. This bug only impacts iOS.

Steps to reproduce:
1. Go to https://codepen.io/daginge/full/bGGxboP on an iPhone running iOS 13.2
2. Tap: "Click me to start testing"
3. Let the test run for about a minute or until it fails, whatever comes first.
4. Observe "NotReadableError"
5. Observe that subsequent clicks to "Click me to start testing" still fails with NotReadableError.
6. Restart Safari
7. Click "Click me to start testing".
8. Observe that getUserMedia now works again.

It can also be observed that once the call fails with NotReadableError and the user goes to the home screen, the "capturing" icon is visible. The webapp cannot stop capturing at this point, and the user believes the page is listening in on calls. ONly way to fix this is to close the tab or kill Safari.

I have been able to reproduce this with timeouts between calls of up to 20 seconds. However, testing this with timeout 0 it does not seem to trigger the issue.

I suspect this issue might have something to do with how Safari on iOS cleans up media access. See also attached image.

Impact:
All services requiring the use of subsequent getUserMedia calls. Keeping the getUserMedia stream around when you don't need it (for example in an application looking to do many subsequent calls without reloading the page) is bad UX, drains the battery, and makes the user believe you are listening when you aren't.

Workaround:
Don't kill the stream, keep it around forever. It's yours now.

[Chad Phillips]

I wonder if this is related to https://bugs.webkit.org/show_bug.cgi?id=179363

[Radar WebKit Bug Importer]

<rdar://problem/57274619>

[youenn fablet]

It might be that https://bugs.webkit.org/show_bug.cgi?id=201638 fixes this issue.
When reproing the issue, we could look at whether there is a sandbox violation happening in the console log.

[Dag-Inge Aas]

Thanks, I'll follow that patch! How will I know when a Safari for iOS build is out so I can test it?

[Dag-Inge Aas]

Re-tested this on iOS 13.3 now. No errors in console.log hinting at any sandbox violation when this happens. Is there some debug log I'm missing here?

[Dag-Inge Aas]

Continued high error rates for this bug. I can reproduce it quite reliably. Any updates on a fix for this? Anything we can do to help the process?

[youenn fablet]

Hi Daginge,

Have you tried the latest iOS 13.4 seed?

[Dag-Inge Aas]

Could not reproduce on latest iOS 13.4 seed as of today. Is there any timeline until release?

[youenn fablet]

Closing now, please reopen if you still see the issue.