Bug 23128 - Add an explicit "get access to media" call
Summary: Add an explicit "get access to media" call
Status: RESOLVED WONTFIX
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: Media Capture and Streams (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: public-media-capture@w3.org
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-02 15:24 UTC by Harald Alvestrand
Modified: 2013-09-17 13:27 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Alvestrand 2013-09-02 15:24:14 UTC
One of the problems with the current method of getting access to media
is that it occurs as a side effect of a call done for other purposes
(GetUserMedia).

The parameters for this aren't ideal to determine the full range of
permissions that a page would want - for instance, a page might first
open a video device, and later open an audio device separately; in our
current models, that would give 2 permissions prompts.

Instead of doing it this way, we could make an explicit call:

void GetMediaPermissions(Permissions permissions,
                            successCallback, errorCallback)

Permissions = enum(
  "videoInputDevices",
  "audioInputDevices",
  // and maybe extend this to
  "deviceEnumeration",
  "screenCapture",
  "windowCapture",
  ....
)

The UA could then use the list of permissions requested to construct an
appropriate UI element for asking permission from the user (or use a
stored permissions model to grant access immediately, if that's the
Right Thing).
In any case, all programs that know what class of permissions they want
can get those permissions with one call, one prompt, no matter what they
do later.

For backwards compatibility, getUserMedia would be documented to have an
implicit call to GetMediaPermissions "behind the curtains".

An earlier attempt was http://dev.w3.org/2009/dap/perms/FeaturePermissions.html - an important difference between that and this proposal is that this proposal explicitly states that one can ask for a set of features, not just one at a time, and that user prompts (and therefore reasonably long delays) are to be expected.
Comment 1 Harald Alvestrand 2013-09-06 09:03:32 UTC
Proposed IDL, based on the DAP IDL:

Navigator implements NavigatorDevicePermissions;

[NoInterfaceObject]
interface NavigatorDevicePermissions {
    DevicePermissionLevel devicePermissionLevel (in DOMString feature);
    void requestDevicePermission (in sequence<DOMString> features,
                            in Function success, in Function failure);
    attribute DOMString[] devicePermissionsImplemented;
};

enum DevicePermissionLevel {
  "UserAllowed",
  "DefaultAllowed",
  "UserDenied",
  "DefaultDenied"
};

// Permissions must be valid members of DevicePermissionNames
// or a subtype that extends it.
enum DevicePermissionNames {
  "videoInputDevices",
  "audioInputDevices",
  "inputDeviceLabels",
  "outputDeviceLabels",
  "screenCapture",
  "windowCapture"
}
Comment 2 Anne 2013-09-06 10:56:28 UTC
Please see http://notifications.spec.whatwg.org/#dom-notification-requestpermission and in particular http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html

There's good reasons why we abandoned this path. Flash tried to do this, Java tried, both are not very successful at conveying to the user what's going on.
Comment 3 Stefan Hakansson LK 2013-09-17 13:27:21 UTC
I could not see any consensus for this change, so I'm resolving this bug as WONTFIX.