Permissions

5.1. Reading the current permission state

5.2. Requesting more permission

Spec authors, please note that algorithms in this section can wait for user input; so they shouldn’t be used from other algorithms running on the main thread.

5.3. Reacting to users revoking permission

When the UA learns that the user no longer intends to grant permission for a realm to use a feature , it must queue a task on the Realm’s settings object ’s responsible event loop to run that feature’s permission revocation algorithm .

8.1. query() method

When the query(permissionDesc) method is invoked, the user agent MUST run the following query a permission algorithm, passing the parameter permissionDesc :

1. If this relevant global object is a Window object, then:
   1. If the current settings object’s associated Document is not fully active , return a promise rejected with a "InvalidStateError" DOMException .
2. Let rootDesc be the object permissionDesc refers to, converted to an IDL value of type PermissionDescriptor . If this throws an exception, return a promise rejected with that exception and abort these steps.
3. Let typedDescriptor be the object permissionDesc refers to, converted to an IDL value of rootDesc . name ’s permission descriptor type . If this throws an exception, return a promise rejected with that exception and abort these steps.
4. Let promise be a newly-created Promise .
5. Return promise and continue the following steps asynchronously.
6. Run the steps to create a PermissionStatus for typedDescriptor , and let status be the result.
7. Run status @ [[query]] . name ’s permission query algorithm , passing status @ [[query]] and status .
8. Resolve promise with status .

10.1. Geolocation

The "geolocation" permission is the permission associated with the usage of the [geolocation-API] . It is a boolean feature and is allowed in non-secure contexts .

10.2. Gamepad

The "gamepad" permission is the permission associated with the usage of the [Gamepad] . It is a boolean feature and is allowed in non-secure contexts .

10.3. Notifications

The "notifications" permission is the permission associated with the usage of the [notifications] API. It is a boolean feature and is allowed in non-secure contexts .

10.4. Push

The "push" permission is the permission associated with the usage of the [push-api] .

permission descriptor type

dictionary PushPermissionDescriptor : PermissionDescriptor {
  boolean userVisibleOnly = false;
};

{name: "push", userVisibleOnly: false} is stronger than {name: "push", userVisibleOnly: true} .

10.5. Midi

The "midi" permission is the permission associated with the usage of [webmidi] . "midi" is allowed in non-secure contexts .

permission descriptor type

dictionary MidiPermissionDescriptor : PermissionDescriptor {
  boolean sysex = false;
};

{name: "midi", sysex: true} is stronger than {name: "midi", sysex: false} .

10.6. Screen wake lock

The "screen-wake-lock" permission is the permission associated with the usage of the [screen-wake-lock] API. It is a boolean feature .

10.7. Media Devices

The "camera" , "microphone" , and "speaker-selection" permissions are associated with permission to use media devices as specified in [GETUSERMEDIA] and [audio-output] .

permission descriptor type

dictionary DevicePermissionDescriptor : PermissionDescriptor {
  DOMString deviceId;
};
dictionary CameraDevicePermissionDescriptor : DevicePermissionDescriptor {
  boolean panTiltZoom = false;
};

A permission covers access to the device given in the associated descriptor.

If the descriptor does not have a deviceId , its semantic is that it queries for access to all devices of that class. Thus, if a query for the "camera" permission with no deviceId returns "granted" , the client knows that there will never be a permission prompt for a camera, and if "denied" is returned, it knows that no getUserMedia request for a camera will succeed.

If a permission state is present for access to some, but not all, cameras, a query without the deviceId will return "prompt" .

{name: "camera", panTiltZoom: true} is stronger than {name: "camera", panTiltZoom: false} .

Note that a "granted" permission is no guarantee that getUserMedia will succeed. It only guarantees that the user will not be prompted for permission. There are many other things (such as constraints or the camera being in use) that can cause getUserMedia to fail.

extra permission data type

A list of deviceId values for the devices the user has made a non-default decision on access to.

permission query algorithm

The permission query algorithm runs the following steps:

1. If permissionDesc .deviceId exists in the extra permission data , set status .state to permissionDesc ’s permission state and terminate these steps.
2. Let global be a copy of permissionDesc with the deviceId member removed.
3. Set status .state to global ’s permission state .

permission request algorithm

The permission request algorithm runs the following steps:

1. Let result be the result of running the boolean permission request algorithm .
2. If result is "granted" , the UA MUST set the "device-info" permission to "granted" for this realm .
3. The UA MAY treat result as new information about the user’s intent with respect to the "device-info" permission for this realm and other realms with the same origin , provided it doesn’t violate the previous step.
4. Return result .

permission revocation algorithm

This is the result of calling the device permission revocation algorithm passing name and deviceId as arguments. If the descriptor does not have a deviceId , then undefined is passed in place of deviceId .

The "device-info" permission controls access to the name and capabilities associated with a deviceId , as well as whether devicechange events fire when the current browsing context is not in focus. The "device-info" permission MUST be revoked when deviceId s for an origin are reset.

10.8. Background Fetch

The "background-fetch" permission is the permission associated with the usage of [background-fetch] .

10.9. Background Sync

The "background-sync" permission is the permission associated with the usage of [web-background-sync] .

10.10. Bluetooth

The "bluetooth" permission ( Web Bluetooth §3.1 Permission API Integration ) controls usage of [web-bluetooth] .

10.11. Persistent Storage

The "persistent-storage" permission ( Storage §5 Persistence permission ) is the permission associated with the usage of the "persistent" storage bucket mode .

10.12. Ambient Light Sensor

The "ambient-light-sensor" permission is the permission associated with the usage of the [ambient-light] API.

Its permission revocation algorithm is the result of calling generic sensor permission revocation algorithm passing it "ambient-light-sensor" as argument.

10.13. Accelerometer

The "accelerometer" permission is the permission associated with the usage of the [accelerometer] API.

Its permission revocation algorithm is the result of calling generic sensor permission revocation algorithm passing it "accelerometer" as argument.

10.14. Gyroscope

The "gyroscope" permission is the permission associated with the usage of the [gyroscope] API.

Its permission revocation algorithm is the result of calling generic sensor permission revocation algorithm passing it "gyroscope" as argument.

10.15. Magnetometer

The "magnetometer" permission is the permission associated with the usage of the [magnetometer] API.

Its permission revocation algorithm is the result of calling generic sensor permission revocation algorithm passing it "magnetometer" as argument.

10.16. Display Capture

The "display-capture" permission is the permission associated with the usage of [screen-capture] .

permission state constraints

Valid values for this descriptor’s permission state are "prompt" and "denied" . The user agent MUST NOT ever set this descriptor’s permission state to "granted" .

10.17. NFC

The "nfc" permission is the permission associated with the usage of the [web-nfc] API.

11.1. Set Permission

The Set Permission extension command simulates user modification of a PermissionDescriptor 's permission state .

The remote end steps are:

1. Let parameters be the parameters argument, converted to an IDL value of type PermissionSetParameters . If this throws an exception, return a WebDriver error with WebDriver error code invalid argument .
2. Let rootDesc be parameters . descriptor .
3. Let typedDescriptor be the object rootDesc refers to, converted to an IDL value of rootDesc . name ’s permission descriptor type . If this throws an exception, return a WebDriver error with WebDriver error code invalid argument .
4. If parameters . state is an inappropriate permission state for any implementation-defined reason, return a WebDriver error with WebDriver error code invalid argument .

   For example, user agents that define the "midi" feature as "always on" may choose to reject command to set the permission state to "denied" at this step.

5. Let settings be the environment settings object of the current browsing context ’s active document .
6. If settings is a non-secure context and rootDesc . name isn’t allowed in non-secure contexts , return a WebDriver error with WebDriver error code invalid argument .
7. If parameters . oneRealm is true, let targets be a list whose sole member is settings .
8. Otherwise, let targets be a list containing all environment settings objects whose origin is the same as the origin of settings .
9. Let tasks be an empty list .
10. For each environment settings object target in targets :
    1. Queue a task task on the permission task source of target ’s relevant settings object 's global object 's browsing context to perform the following step:
       1. Interpret parameters . state as if it were the result of an invocation of permission state for typedDescriptor with the argument target made at this moment.
    2. Append task to tasks .
11. Wait for all tasks in tasks to have executed.
12. Return success with data null .

{
  "descriptor": {
    "name": "midi",
    "sysex": true
  },
  "state": "granted"
}