Determine how PTZ permission prompts are supposed to work #243
Comments
Maybe we need to be more verbose in the spec, but there's an example in the spec to show how PTZ works with gUM(). Also, from the ptz-explainer const panTiltZoomPermissionStatus = await navigator.permissions.query({
name: "camera",
panTiltZoom: true,
});
if (panTiltZoomPermissionStatus.state == "granted") {
// User has granted access to this website to control camera PTZ.
}
We touched upon this in the ptz-explainer. From a Privacy and Security angle, having 2 separate permissions (camera and ptz) makes sense, where From UX perspective, we thought it's better to combine both camera and PTZ permission in a single prompt (avoid prompt fatigue).
|
|
Spec says for tilt for instance:
Would it help if we were indicating that if gUM requests ptz capability, and a device with the capability is selected, it should prompt for that permission? |
|
@youennf : gentle ping. |
Yes, I would think it helps.
I am not clear on whether it is possible for a browser to allow a user to say: yes for camera but no for PTZ in case of getUserMedia({ video : { pan : true })? Another related question (maybe this is already clear in the spec). If PTZ is supported by the camera and page has a MediaStreamTrack, what would return capabilities.pan and applyConstraints({pan: xxx}) in the following cases:
The primer also says: "It will also be possible for users to revoke the PTZ permission by itself, while keeping the camera permission". Is there anything the spec should say about this case? For instance, in terms of what happens to live cameraPTZ track(s)? media capture main indicates (not very strongly though) that the live tracks get ended if permission is revoked. |
I'll work on this.
Nope. With
It could use the permissions API indeed. See below const panTiltZoomPermissionStatus = await navigator.permissions.query({
name: "camera",
panTiltZoom: true,
});
panTiltZoomPermissionStatus.onchange = () => {
// User has changed PTZ permission status.
}Using
You would still use
You can give a try to the Chromium implementation by running Chrome 86 with
In both cases,
We don't end live tracks for now, but that's something we could do indeed. |
I think I saw these checks for applyConstraints in the spec.
AIUI, for both queries, getUserMedia will do the same permission request made with: { name: "camera", panTiltZoom: true } and the result of the request is either denied or granted. This does seem to contradict what the primer says:
|
You're absolutely right. I've filed #245
In the second query, if there are no cameras with PTZ capabilities, the PTZ request will be ignored and it will be treated like a regular camera request.
|
It seems you say that, if there is no PTZ camera, the permission request will be { name: "camera", panTiltZoom: false }.
Now, let's take the case of a setup with a PTZ camera but user persistently denied PTZ permission. getUserMedia({ video: { advanced: [{ pan: true }] } }) will trigger a permission request of { name: "camera", panTiltZoom: true }. The result of the permission request will be 'denied' since PTZ permission is denied. getUserMedia will then always reject. |
It's not and it should be fixed in the spec. Thanks for raising this issue.
With |
Where is this algorithm specified? |
|
Advanced constraints are a concept of the mediacapture-main spec, so it should automatically apply to the mediacapture-image spec. I guess our spec should say that processing of the PTZ constraints follows the same rules as in the SelectSettings algorithm of mediacapture-main, except where explicitly noted (e.g., the boolean syntactic sugar). Would this help? |
|
Constraints are validated/selected against what the devices can do, not what user allowed or denied. |
|
It is clear to me that this spec has the goal of having separate permissions for generic camera and PTZ. However, I'm not sure it is a goal of the spec is to mandate that browsers need to provide a prompt that allows to simultaneously grant the camera permission and denies the PTZ one in case none of the permissions have been persisted. Can anyone confirm? I believe the current Chromium prototype implementation works with more traditional binary prompts that accept/reject everything that is requested. It is possible that the prompt only includes only camera, or only PTZ, or both, depending on the request and the persistent status of permissions. In my opinion, implementations should have flexibility wrt to how they want to implement the prompts. |
Agreed with @guidou that we need to understand precisely what are the user agent (UI/prompt) requirements this spec mandates.
Agreed again.
That said, it would be interesting to get input from potential customers of this API. |
|
When building the PTZ permission prompt in Chromium we considered prompting on Do you think this is a place where implementations could reasonably disagree or should the specification mandate or forbid supporting a permission request as part of |
|
For info, here's where we've talked about PTZ permission request in |
@youennf How would you be able to detect camera is PTZ when capabilities and settings are not exposed when the PTZ permission has not been granted? |
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:
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:
The text was updated successfully, but these errors were encountered: