[mediacapture-image] Determine how PTZ permission prompts are supposed to work (#243)

youennf has just created a new issue for https://github.com/w3c/mediacapture-image:

== Determine how PTZ permission prompts are supposed to work ==
The spec is not very clear about how PTZ permission is asked as part of the getUserMedia call.
It would be good to identify how this is supposed to work and specify it as precisely as possible.
This might require defining potential hooks from mediacapture-main spec and help clearing potential fingerprinting issues.

Also, from what I understood, the goal of the proposal is that a single prompt may be implemented to allow the user to either:
- deny camera and PTZ
- deny PTZ but allow camera
- allow camera and PTZ
Is that correct?
This is somehow new to getUserMedia related prompts, which are currently mostly boolean.
If you add audio to the mix, this makes the prompt request to the user potentially complex.

To be noted also that there is a desire to move to in-chome device picker for getUserMedia.
It would be good to validate that the PTZ proposed approach can be adequately implemented in that scenario.
The closest example I can think of might be screen sharing, user being able to optionally select output audio.

To help driving the discussion, it would be good to document other possibilities, with pros and cons, or at least why these alternatives were discarded. I am for instance thinking of:
- A separate API dedicated to get PTZ camera access
- getUserMedia to get camera (with ability to favour PTZ device if any is available) and applyConstraints to start using PTZ, the latter gated by a PTZ specific permission (with a prompt at applyConstraints time or pre-granting at getUserMedia time).

Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/243 using your GitHub account


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

Received on Thursday, 6 August 2020 17:16:34 UTC