[Webkit-unassigned] [Bug 264288] New: Ending track on another getUserMedia is not sound

[bugzilla-daemon at webkit.org]

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

            Bug ID: 264288
           Summary: Ending track on another getUserMedia is not sound
           Product: WebKit
           Version: Safari 16
          Hardware: iPhone / iPad
                OS: iOS 16
            Status: NEW
          Severity: Minor
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: webkit-bugzilla at lavrins.com
                CC: youennf at gmail.com

On iOS, when requesting camera video through getUserMedia twice, it ends the existing MediaStreamTrack. This change was implemented in https://bugs.webkit.org/show_bug.cgi?id=179363.

That might be an expected situation when _exactly_ the same device is requested twice. However, on iPhone, it works that way even if a different camera module is requested or even if there's already an existing front camera track and back camera being requested.

This behavior is problematic for several reasons:

        1.      It is unpredictable. Even when using getUserMedia with a different device id and `groupId` from an existing MediaStreamTrack, there is no guarantee that it won't stop any of the existing tracks.
        2.      It is non-deterministic. There is no way to determine in advance if the requested devices belong to a group that is already in use.
        3.      It is inconsistent with other operating systems. On Windows, a device that can't be used twice raises an explicit exception in getUserMedia, the same as on Android. On MacOS, it is possible to reuse the same devices without any restrictions.

All of this makes it difficult to use when a service allows users to work with multiple cameras because it is not possible to know which device is already in use. While it's understandable that the main or front camera can't be reused, a user could have an external device connected, and currently, there is no way to determine if it's part of the device's camera modules.

Here are a few proposed solutions to address this issue:

        1.      Instead of ending the existing MediaStreamTrack, raise an explicit "not allowed" error when a getUserMedia request is made with a constrained device ID that matches a device already in use. This approach would ensure consistency across all operating systems and browsers.
        2.      Use the same groupId for all iPhone/iPad cameras in MediaDeviceInfo. While this is not ideal because other devices might have a shared group ID and support simultaneous use of each device, it would at least provide a way to identify that the requested track probably belongs to the same device and exclude it from the list of options.
        3.      Add an identifier to the MediaDeviceInfo label that indicates it is the device's built-in camera, regardless of the system locale. Currently, the label does not clearly indicate that it's built-in (e.g., "Front Camera," "Back Triple Camera"), and it is also localized, with unique labels for each of the 41 languages supported by iOS.
        4.      Allow front and back cameras to work simultaneously.

-- 
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/20231106/322adbd8/attachment-0001.htm>