Re: [mediacapture-main] Bug in spec: circular dependency for enumerateDevices() (#709)

The tail is wagging the dog here?

Access to APIs is being _restricted to when the capture indicator is on screen_. Better to have a clear API design, and derive the capture indicator from it.

The side effects are being tested in this ticket: apprehension around failure cases in case they reveal information without indicating; and a 'guaranteed to succeed' codepath is a burden for both the spec and developers, but is needed to satisfy the problem which opened this ticket.

Your goals are increasingly clearer, why not just implement those goals?

* the capture indicator ("camera" icon in URL bar)
  * present from the moment the page accesses any personalised information
    * personalised information could be: noise on the soundcard, a video frame, or device IDs
  * persists for the lifetime of the tab/page
* the record indicator ("red blob" icon in the tab)
  * directly related to when audio or video device is streaming
  * removed when streaming completes
* explicit user permission step
  * if no permissions is given, do not reveal any personalised information
  * browser policy may remember this between session
* no change needed to existing JavaScript code

To achieve the above:

* Access to both APIs, enumerateDevices() and getUserMedia() based on the permission check _with no extra conditions_
* Activate the capture indicator _on any reveal of information_ including:
  * device opened successfully
  * device failed to open
  * reveal of any deviceID (enumerateDevices)

With this, no complexity or change is pushed on the developer compared to their current experience in eg. Chromium. When returning to a web page, the intial call can be to either enumerateDevices() or getUserMedia(deviceID: xxx) and get the intuitive result (no need to quash failure cases, ignore 'strict' requirements, or restrict acccess)

But, crucially, all of the goals of the capture indicator are achieved as well (and clearly defined)

And the other benefits are:

* Developer does not open an alternative device (eg. getUserMedia({audio:true})) to acquire access enumerateDevices() or test if a device is present; which is inefficient and quite arbitary.
* The permissions relationship is very straightforward for a developer to understand and work with
* Reduction in edge cases for the spec maintainers; less complexity
* Reduction in edge cases for developer, especially on failures
* Intuitive API response when there is eg. no camera or no audio interface.


-- 
GitHub Notification of comment by hills
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/709#issuecomment-691139860 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 11 September 2020 14:47:40 UTC