-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distinguish cancellations from absent OS permissions #281
Comments
(I imagine |
Looking at https://wicg.github.io/serial/, it seems like you could also create your own DOMException like https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/bindings/exception_code.h;l=107;drc=b74163d3d63e781ce9899ec6a4e5a7c113d960b9 suggests they are more specs defining their own DOMExceptions. |
Using |
Not sure if it helps but there is an OverconstrainedError in Media Capture and Streams. |
It is not in the Web Serial API. The |
Gotcha. Works for me. |
Keeping In general, I think the UA is ideally suited for helping users understand what is going on, whether they should care about changing permissions, and if so how to do it. Also, this does not seem specific to getDisplayMedia. IIRC, similar discussions happened for getUserMedia. |
Do we know of precedents where the message's contents are specified?
You'd think so, but in practice, no browser I know of does that. Realistically, when can we expect to get to it? Until we do, Web applications are trying to fill in the gap; helping them do so easily and interoperably should be easy for us.
Agreed. |
Concrete proposal - following the example set by RTCError, we extend DOMException as follows: enum GetDisplayMediaNotAllowedReason {
"user-rejected",
"operating-system-disallowed",
};
dictionary GetDisplayMediaNotAllowedErrorInit {
required GetDisplayMediaNotAllowedReason reason;
};
interface GetDisplayMediaNotAllowedError : DOMException {
constructor(optional DOMString message = "", GetDisplayMediaNotAllowedErrorInit init);
readonly attribute GetDisplayMediaNotAllowedReason reason;
}; The ctor sets the name attribute to the value NotAllowedError. Wdyt? (@alvestrand, @youennf, @jan-ivar) |
NotAllowedError? |
Coincidentally, there was a pointer passed by today about guidelines for extending DOMError with extra info: https://webidl.spec.whatwg.org/#idl-DOMException-derived-interfaces |
Thanks. Made the correction.
Thanks for sharing. |
I am curious how it would work when calling |
My reading here is that this is recommending a non-optional dictionary. But I guess the dictionary could have a default value to the |
Isn't this what permissions.query is for? |
A number of things were said during the interim meeting just now, but for me the most compelling is that |
FYI Firefox rejects with We find support for this in: "If no sources of type T are available, reject p with a new DOMException object whose name attribute has the value NotFoundError." We take it to mean what's "available" to the user agent. Firefox does the same for camera and microphone. This is a bit of a fingerprinting vector, so we're open to discussing changing this. |
Shall we go with this proposal then? IIRC, @youennf was on board with that too. |
|
Both |
When the dialog is shown and user presses |
Sorry I mistyped. I meant to ask, when would Chrome return NotFoundError from getDisplayMedia today? |
If query() still yields I'd like to understand when this is insufficient. I'm ignoring a user somehow managing to reconfigure their permissions (in the OS or browser) at the exact same time they also somehow manage to dismiss the prompt. |
I'd have to check. Assume, for the sake of argument, that Chrome does not currently use |
The spec is already talking about
Somehow related to this thread but we can note that, for getUserMedia, |
I wonder if a subclass, |
This is known. Both Chrome and Firefox report 1 camera and 1 microphone without macOS permission.
Apps can disambiguate NotFoundError using enumerateDevices(). But yes gUM here is a side-track. |
I like this idea.
What would this solve? Inheriting off DOMException is normally only done to add members to the interface. |
This issue had an associated resolution in WebRTC February 2024 meeting – 20 February 2024 (Distinguish cancellations from absent OS permissions #281):
|
Video conferencing apps run into a common issue - the app offers the user the ability to share their screen, but when the user tries to avail oneself of the option, it turns out that the browser is lacking the necessary OS permissions.
Worse, the app doesn't have a standard way of distinguishing missing OS permissions from a normal cancellation. In practice, both Chrome and Firefox set the
message
to"Permission denied by system"
. But that's not specified.In the short term, I suggest that the
Permission Failure
step in the gDM algorithm be modified to set either a differentname
,message
orcode
for failures stemming from lacking OS permissions.In the mid term, I suggest that we think of something that could allow the app to query and see if the browser even has the prerequisite permissions. (Concerns of fingerprinting could be mitigated by gating this on mic/camera permissions.)
In the long term, one might argue that everyone should move to a model like Apple's macOS-based picker. I would object on the grounds that OS admin policies might still block such APIs.
The text was updated successfully, but these errors were encountered: