[Webkit-unassigned] [Bug 200953] New: iOS 13 Beta 7, multiple gUM() requests can result in unexpected failures in certain circumstances

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 20 17:08:55 PDT 2019


https://bugs.webkit.org/show_bug.cgi?id=200953

            Bug ID: 200953
           Summary: iOS 13 Beta 7, multiple gUM() requests can result in
                    unexpected failures in certain circumstances
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: iPhone / iPad
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: webkit at xylil.com
                CC: youennf at gmail.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190821/cf4faa68/attachment.html>


More information about the webkit-unassigned mailing list