From b9c08cb5b3f2923e51334e0c2a6dd5658531012e Mon Sep 17 00:00:00 2001 From: Mike Taylor Date: Tue, 13 Jun 2023 14:02:07 +0000 Subject: [PATCH] Add missing semicolon to WebIDL example (#417) SHA: f647e6d85615057f5eccb70cfe3b0a4103e4dcc0 Reason: push, by miketaylr Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- index.html | 429 ++++++++++++++++++++++++++--------------------------- 1 file changed, 214 insertions(+), 215 deletions(-) diff --git a/index.html b/index.html index dd36306..0c68294 100644 --- a/index.html +++ b/index.html @@ -1,6 +1,6 @@ - +
@@ -270,7 +270,7 @@

Permissions

Interacting with Permissions for Powerful Features

-

W3C Editor's Draft

+

W3C Editor's Draft

More details about this document
@@ -325,10 +325,10 @@

Permissions

desktop
-
- Android Chrome logo108 -
- Android Firefox logo107 +
+ Android Chrome logo114 +
+ Android Firefox logo113
Android UC logo13.4
@@ -345,11 +345,10 @@

Permissions

Copyright © - 2022 + 2023 - W3C® (MIT, - ERCIM, Keio, - Beihang). W3C + World Wide Web Consortium. + W3C® liability, trademark and permissive document license rules apply. @@ -470,7 +469,7 @@

Permissions

This section is non-normative.

- Specifications can define features that are explicitly identified as a powerful feature. These features are said to be "powerful" in that they can have significant + Specifications can define features that are explicitly identified as a powerful feature. These features are said to be "powerful" in that they can have significant privacy, security, and performance implications. As such, users rely on user agents to deny sites the ability to use these features until they have given express permission, and usually only granting this ability for a limited amount of time. Express permission to @@ -478,8 +477,8 @@

Permissions

- On the left, a mockup of a notifications prompt with an allow and don't allow buttons that states 'the website example.com would like to send you notifications'. On the right, a prompt near the URL bar asking to give permission to the camera and microphone to the example site. -
Figure 1 + On the left, a mockup of a notifications prompt with an allow and don't allow buttons that states 'the website example.com would like to send you notifications'. On the right, a prompt near the URL bar asking to give permission to the camera and microphone to the example site. +
Figure 1 Sketches of possible permission prompt types
@@ -494,8 +493,8 @@

Permissions

- A mockup of a settings page that would allow a user to set or reset defaults for location, camera, microphone, motion sensors, and notifications permissions. -
Figure 2 + A mockup of a settings page that would allow a user to set or reset defaults for location, camera, microphone, motion sensors, and notifications permissions. +
Figure 2 A sketch of a possible site-specific permissions controls UI
@@ -527,7 +526,7 @@

Permissions

This example simultaneously checks the state of the "geolocation" and "notifications" - powerful features: + powerful features:

@@ -570,7 +569,7 @@

Permissions

- This section specifies a model for permissions to use powerful features on the Web + This section specifies a model for permissions to use powerful features on the Web platform.

3.1 @@ -579,12 +578,12 @@

Permissions

A permission represents a user's decision to allow a web - application to use a powerful feature. This decision is represented as a permission - state. + application to use a powerful feature. This decision is represented as a permission + state.

Express permission refers to the user - granting the web application the ability to use a powerful feature. + granting the web application the ability to use a powerful feature.

Note: Limitations and extensibility

- Conceptually, a permission for a powerful feature can be in one of the following + Conceptually, a permission for a powerful feature can be in one of the following states:

Denied:
- The user, or the user agent on the user's behalf, has denied access to this powerful feature. The caller will can't use the feature. + The user, or the user agent on the user's behalf, has denied access to this powerful feature. The caller will can't use the feature.
Granted:
- The user, or the user agent on the user's behalf, has given express permission to - use a powerful feature. The caller will can use the feature possibly without having - the user agent asking the user's permission. + The user, or the user agent on the user's behalf, has given express permission to + use a powerful feature. The caller will can use the feature possibly without having + the user agent asking the user's permission.
Prompt:
- The user has not given express permission to use the feature (i.e., it's the same - as denied). It also means that if a caller attempts to use the feature, - the user agent will either be prompting the user for permission or access to the - feature will be denied. + The user has not given express permission to use the feature (i.e., it's the same + as denied). It also means that if a caller attempts to use the feature, + the user agent will either be prompting the user for permission or access to the + feature will be denied.

@@ -637,27 +636,27 @@

Permissions

Note: What constitutes an implicit signal?

- Every permission has a lifetime, - which is the duration for which a particular permission remains granted - before it reverts back to its default state. A lifetime - could be until a particular Realm is destroyed, until a particular - top-level browsing context is destroyed, a particular amount of time, or be infinite. - The lifetime is negotiated between the end-user and the user agent when the user - gives express permission to use a feature—usually via some permission UI or + Every permission has a lifetime, + which is the duration for which a particular permission remains granted + before it reverts back to its default state. A lifetime + could be until a particular Realm is destroyed, until a particular + top-level browsing context is destroyed, a particular amount of time, or be infinite. + The lifetime is negotiated between the end-user and the user agent when the user + gives express permission to use a feature—usually via some permission UI or user-agent defined policy.

Every permission has a default state (usually - prompt), which is the state that the permission is in when - the user has not yet given express permission to use the feature or it has been - reset because its lifetime has expired. + prompt), which is the state that the permission is in when + the user has not yet given express permission to use the feature or it has been + reset because its lifetime has expired.

3.2 @@ -666,76 +665,76 @@

Permissions

The user agent maintains a single permission store which is a - list of permission store entries. Each particular entry denoted by its - descriptor and key can only appear + list of permission store entries. Each particular entry denoted by its + descriptor and key can only appear at most once in this list.

- The user agent MAY remove entries from the permission store when their respective - permission's lifetime has expired. + The user agent MAY remove entries from the permission store when their respective + permission's lifetime has expired.

- A permission store entry is a tuple - of PermissionDescriptor descriptor, permission key key, and state state. + A permission store entry is a tuple + of PermissionDescriptor descriptor, permission key key, and state state.

To get a permission store entry given a - PermissionDescriptor descriptor and permission key key: + PermissionDescriptor descriptor and permission key key:

  1. - If the user agent's permission store contains an entry whose - descriptor is descriptor, and whose key is equal to key given descriptor, return that entry. + If the user agent's permission store contains an entry whose + descriptor is descriptor, and whose key is equal to key given descriptor, return that entry.
  2. Return null.

To set a permission store entry given a - PermissionDescriptor descriptor, a permission key key, and a - state state, run these steps: + PermissionDescriptor descriptor, a permission key key, and a + state state, run these steps:

    -
  1. Let newEntry be a new permission store entry whose descriptor is descriptor, and whose key is key, - and whose state is state. +
  2. Let newEntry be a new permission store entry whose descriptor is descriptor, and whose key is key, + and whose state is state.
    3. -
  3. If the user agent's permission store contains an entry whose - descriptor is descriptor, and whose key is equal to key given descriptor, replace +
  4. If the user agent's permission store contains an entry whose + descriptor is descriptor, and whose key is equal to key given descriptor, replace that entry with newEntry and abort these steps.
    5. -
  5. Append newEntry to the user agent's permission store. +
  6. Append newEntry to the user agent's permission store.

To remove a permission store entry given a - PermissionDescriptor descriptor and permission key key, run these steps: + PermissionDescriptor descriptor and permission key key, run these steps:

    -
  1. Remove the entry whose descriptor is - descriptor, and whose key is equal to - key given descriptor, from the user agent's permission store. +
  2. Remove the entry whose descriptor is + descriptor, and whose key is equal to + key given descriptor, from the user agent's permission store.

- A permission key has its type defined by a feature's permission key type. + A permission key has its type defined by a feature's permission key type.

Note

- To determine whether a permission key key1 is equal to a permission key key2, given a + To determine whether a permission key key1 is equal to a permission key key2, given a PermissionDescriptor descriptor, run the following steps:

    -
  1. If key1 is not of descriptor's permission key type or key2 - is not of descriptor's permission key type, return false. +
  2. If key1 is not of descriptor's permission key type or key2 + is not of descriptor's permission key type, return false.
    3. -
  3. Return the result of running the permission key comparison algorithm for the feature named by descriptor's name, +
  4. Return the result of running the permission key comparison algorithm for the feature named by descriptor's name, passing key1 and key2.
@@ -746,22 +745,22 @@

Permissions

A powerful feature is a web platform - feature (usually an API) for which a user gives express permission before the feature + feature (usually an API) for which a user gives express permission before the feature can be used. Except for a few notable exceptions (e.g., the Notifications API Standard), most - powerful features are also policy-controlled features. For powerful features that are - also policy-controlled features, [Permissions-Policy] controls whether a - document is allowed to use a given feature. That is, a powerful feature can only - request express permission from a user if the document has permission delegated - to it via the corresponding policy-controlled feature (see example below). Subsequent - access to the feature is determined by the user having granted permission, - or by satisfying some criteria that is equivalent to a permission grant. + powerful features are also policy-controlled features. For powerful features that are + also policy-controlled features, [Permissions-Policy] controls whether a + document is allowed to use a given feature. That is, a powerful feature can only + request express permission from a user if the document has permission delegated + to it via the corresponding policy-controlled feature (see example below). Subsequent + access to the feature is determined by the user having granted permission, + or by satisfying some criteria that is equivalent to a permission grant.

- A powerful feature is identified by its name, which is a string literal (e.g., "geolocation"). + A powerful feature is identified by its name, which is a string literal (e.g., "geolocation").

- The user agent tracks which powerful features the user has permission to use - via the environment settings object. + The user agent tracks which powerful features the user has permission to use + via the environment settings object.

3.3.1 Aspects

- Each powerful feature can define zero or more additional aspects. An aspect is defined as WebIDL dictionary that - inherits from PermissionDescriptor and serves as a WebIDL - interface's permission descriptor type. + Each powerful feature can define zero or more additional aspects. An aspect is defined as WebIDL dictionary that + inherits from PermissionDescriptor and serves as a WebIDL + interface's permission descriptor type.

- The permissions task source is a task source used to perform - permissions-related tasks in this specification. + The permissions task source is a task source used to perform + permissions-related tasks in this specification.

@@ -834,25 +833,25 @@

Permissions

- When a conforming specification specifies a powerful feature + When a conforming specification specifies a powerful feature it:

    -
  1. MUST give the powerful feature a name in the form of a ascii lowercase string. +
  2. MUST give the powerful feature a name in the form of a ascii lowercase string.
    3. -
  3. MAY define a permission descriptor type that inherits from +
  4. MAY define a permission descriptor type that inherits from PermissionDescriptor.
    5. -
  5. MAY define zero or more aspects. +
  6. MAY define zero or more aspects.
  7. MAY override the algorithms and types given below if the defaults are not suitable for - a particular powerful feature. + a particular powerful feature.
    8. -
  8. MUST register the powerful feature in the Permissions Registry. +
  9. MUST register the powerful feature in the Permissions Registry.

- Registering the newly specified powerful features in the Permissions Registry + Registering the newly specified powerful features in the Permissions Registry gives this Working Group an opportunity to provide feedback and check that integration with this specification is done effectively.

@@ -878,7 +877,7 @@

Permissions

{name: "midi", sysex: true} ("midi-with-sysex") is - stronger than {name: "midi", sysex: false} + stronger than {name: "midi", sysex: false} ("midi-without-sysex"), so if the user denies access to midi-without-sysex, the UA must also deny access to midi-with-sysex, and similarly if the user grants access to midi-with-sysex, the user agent must also grant access to midi-without-sysex. @@ -898,7 +897,7 @@

Permissions

Some powerful features have more information associated with them than just a - PermissionState. Each of these features defines an extra permission data type. + PermissionState. Each of these features defines an extra permission data type.

Note

For example, getUserMedia() needs to determine which cameras @@ -909,19 +908,19 @@

Permissions

environment settings object settings is the result of the following algorithm:

    -
  1. If settings wasn't passed, set it to the current settings object. +
  2. If settings wasn't passed, set it to the current settings object.
  3. If there was a previous invocation of this algorithm with the same name and settings, returning previousResult, and the user agent has not received new information about the user's intent since that invocation, return previousResult.
    4. -
  4. Return the instance of name's extra permission data type +
  5. Return the instance of name's extra permission data type that matches the UA's impression of the user's intent, taking into account any - extra permission data constraints for name. + extra permission data constraints for name.

- If specified, the extra permission data algorithm is usable for + If specified, the extra permission data algorithm is usable for this feature.

@@ -930,8 +929,8 @@

Permissions

:
- Constraints on the values that the user agent can return as a powerful feature's - extra permission data. Defaults to no constraints beyond the user's + Constraints on the values that the user agent can return as a powerful feature's + extra permission data. Defaults to no constraints beyond the user's intent.
@@ -946,11 +945,11 @@

Permissions

- Takes an instance of the permission descriptor type and a new or - existing instance of the permission result type, and updates the - permission result type instance with the query result. Used by + Takes an instance of the permission descriptor type and a new or + existing instance of the permission result type, and updates the + permission result type instance with the query result. Used by Permissions' query(permissionDesc) method and the - PermissionStatus update steps. If unspecified, this defaults to the default + PermissionStatus update steps. If unspecified, this defaults to the default permission query algorithm.

@@ -969,9 +968,9 @@

Permissions

- The type of permission key used by the feature. Defaults to origin. A feature - that specifies a custom permission key type MUST also specify a - permission key generation algorithm. + The type of permission key used by the feature. Defaults to origin. A feature + that specifies a custom permission key type MUST also specify a + permission key generation algorithm.

@@ -980,16 +979,16 @@

Permissions

- Takes an environment settings object, and returns a new permission key. If + Takes an environment settings object, and returns a new permission key. If unspecified, this defaults to the default permission key generation algorithm. A - feature that specifies a custom permission key generation algorithm MUST also specify a permission key comparison algorithm. + feature that specifies a custom permission key generation algorithm MUST also specify a permission key comparison algorithm.

The default permission key generation algorithm, given an - environment settings object settings, runs the following steps: + environment settings object settings, runs the following steps:

    -
  1. Return settings's top-level origin. +
  2. Return settings's top-level origin.
Note: Permission Delegation
- A permission lifetime: + A permission lifetime:

- Specifications that define one or more powerful features SHOULD suggest a - permission lifetime that is best suited for the particular feature. + Specifications that define one or more powerful features SHOULD suggest a + permission lifetime that is best suited for the particular feature. Some guidance on determining the lifetime of a permission is noted below, with a strong - emphasis on user privacy. If no lifetime is specified, the user agent + emphasis on user privacy. If no lifetime is specified, the user agent provides one.

- When the permission lifetime expires for an origin: + When the permission lifetime expires for an origin:

    -
  1. Set the permission back to its default permission state (e.g., by setting it - back to "prompt"). +
  2. Set the permission back to its default permission state (e.g., by setting it + back to "prompt").
    3. -
  3. For each browsing context associated with the origin (if any), queue a global task on the permissions task source with the browsing context's global object to run the permission revocation algorithm. +
  4. For each browsing context associated with the origin (if any), queue a global task on the permissions task source with the browsing context's global object to run the permission revocation algorithm.
Note: Determining the lifetime of a permission
@@ -1082,10 +1081,10 @@

Permissions

- An PermissionState value that serves as a permission's default state of a powerful feature. + An PermissionState value that serves as a permission's default state of a powerful feature.

- If not specified, the permission's default state is + If not specified, the permission's default state is "prompt".

@@ -1105,15 +1104,15 @@

Permissions

To get the current - permission state, given a name name and an optional - environment settings object settings, run the following steps. This algorithm + permission state, given a name name and an optional + environment settings object settings, run the following steps. This algorithm returns a PermissionState enum value.

  1. Let descriptor be a newly-created PermissionDescriptor with name initialized to name.
    2. -
  2. Return the permission state of descriptor with settings. +
  3. Return the permission state of descriptor with settings.

@@ -1122,31 +1121,31 @@

Permissions

PermissionState enum value:

    -
  1. If settings wasn't passed, set it to the current settings object. +
  2. If settings wasn't passed, set it to the current settings object.
    3. -
  3. If settings is a non-secure context, return "denied". +
  4. If settings is a non-secure context, return "denied".
  5. Let feature be descriptor's name.
    6. -
  6. If there exists a policy-controlled feature for feature and settings' - relevant global object has an associated Document run the following step: +
  7. If there exists a policy-controlled feature for feature and settings' + relevant global object has an associated Document run the following step:
      -
    1. Let document be settings' relevant global object's associated Document. +
    2. Let document be settings' relevant global object's associated Document.
    3. If document is not allowed to use feature, return "denied".
    8. -
  8. Let key be the result of generating a permission key for descriptor with settings. +
  9. Let key be the result of generating a permission key for descriptor with settings.
    10. -
  10. Let entry be the result of getting a permission store entry with descriptor and key. +
  11. Let entry be the result of getting a permission store entry with descriptor and key.
  12. If entry is not null, return a PermissionState enum value from entry's - state. + state.
  13. Return the PermissionState enum value that represents the permission state of - feature, taking into account any permission state constraints for + feature, taking into account any permission state constraints for descriptor's name.
@@ -1174,19 +1173,19 @@

Permissions

Ask the user for express permission for the calling algorithm to use the powerful feature described by descriptor. -
  • If the user gives express permission to use the powerful feature, set current +
  • If the user gives express permission to use the powerful feature, set current state to "granted"; otherwise to "denied". The user's interaction may provide new information about the user's intent for the - origin. + origin.
    Note

    This is intentionally vague about the details of the permission UI and how the user agent infers user intent. User agents should be able to explore lots of UI within this framework.

    • -
  • Let key be the result of generating a permission key with the current settings object. +
  • Let key be the result of generating a permission key with the current settings object.
    • -
  • Queue a task on the current settings object's responsible event loop to set a permission store entry with descriptor, +
  • Queue a task on the current settings object's responsible event loop to set a permission store entry with descriptor, key, and current state.
  • Return current state. @@ -1253,13 +1252,13 @@

    Permissions

    When the user agent learns that the user no longer intends to grant permission to use a feature described by the PermissionDescriptor descriptor in the context described - by the permission key key, react to the user revoking permission by + by the permission key key, react to the user revoking permission by running these steps:

      -
    1. Run descriptor's name's permission revocation algorithm. +
    2. Run descriptor's name's permission revocation algorithm.
      3. -
    3. Remove a permission store entry with descriptor and key. +
    4. Remove a permission store entry with descriptor and key.
    @@ -1312,9 +1311,9 @@

    Permissions

    - MDN🚫 + MDN  WorkerNavigator/permissions -

    This feature has limited support.

    + @@ -1340,9 +1339,9 @@

    Permissions

    - + - + @@ -1476,10 +1475,10 @@

    Permissions

    permissionDesc:

      -
    1. If this's relevant global object is a Window object, then: +
    2. If this's 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 an +
      2. If the current settings object's associated Document is not + fully active, return a promise rejected with an "InvalidStateError" DOMException.
      @@ -1487,13 +1486,13 @@

      Permissions

      Let rootDesc be the object permissionDesc refers to, converted to an IDL value of type PermissionDescriptor.

      3. -
    3. If the conversion throws an exception, return a promise +
    4. If the conversion throws an exception, return a promise rejected with that exception.
      5. -
    5. If rootDesc["name"] is not supported, return a promise rejected with a TypeError. +
    6. If rootDesc["name"] is not supported, return a promise rejected with a TypeError.
      Note: Why is this not an enum?
    7. Let typedDescriptor be the object permissionDesc refers to, converted to an - IDL value of rootDesc's name's permission descriptor type. + IDL value of rootDesc's name's permission descriptor type.
      8. -
    8. If the conversion throws an exception, return a promise +
    9. If the conversion throws an exception, return a promise rejected with that exception.
      10. -
    10. Let promise be a new promise. +
    11. Let promise be a new promise.
      12. -
    12. Return promise and continue in parallel: +
    13. Return promise and continue in parallel:
      1. Let status be create a PermissionStatus with typedDescriptor.
      2. Let query be status's [[query]] internal slot.
        3. -
      3. Run query's name's permission query algorithm, passing query and status. +
      4. Run query's name's permission query algorithm, passing query and status.
        5. -
      5. Queue a global task on the permissions task source with this's - relevant global object to resolve promise with status. +
      6. Queue a global task on the permissions task source with this's + relevant global object to resolve promise with status.
      14. @@ -1587,12 +1586,12 @@

      Permissions

      PermissionStatus instances are created with a [[query]] internal slot, - which is an instance of a feature's permission descriptor type. + which is an instance of a feature's permission descriptor type.

      The "granted", "denied", and "prompt" enum values - represent the concepts of granted, denied, and - prompt respectively. + represent the concepts of granted, denied, and + prompt respectively.

      6.3.1 Creating instances @@ -1605,9 +1604,9 @@

      Permissions

    14. Let name be permissionDesc's name.
      15. -
    15. Assert: The feature identified by name is supported by the user agent. +
    16. Assert: The feature identified by name is supported by the user agent.
      17. -
    17. Let status be a new instance of the permission result type identified by name: +
    18. Let status be a new instance of the permission result type identified by name:
      1. Initialize status's [[query]] internal slot to permissionDesc. @@ -1724,9 +1723,9 @@

        Permissions

    Chrome
    Opera Android ?
    SafariNo16.4+
    Safari iOS ?
    @@ -1752,9 +1751,9 @@

    Permissions

    - + - + @@ -1775,26 +1774,26 @@

    Permissions

    event handler event type is change.

    - Whenever the user agent is aware that the state of a PermissionStatus instance + Whenever the user agent is aware that the state of a PermissionStatus instance status has changed, it asynchronously runs the PermissionStatus update steps:

      -
    1. If this's relevant global object is a Window object, then: +
    2. If this's relevant global object is a Window object, then:
        -
      1. Let document be status's relevant global object's associated Document. +
      2. Let document be status's relevant global object's associated Document.
        3. -
      3. If document is null or document is not fully active, terminate +
      4. If document is null or document is not fully active, terminate this algorithm.
    3. Let query be status's [[query]] internal slot.
      4. -
    4. Run query's name's permission query algorithm, passing query and status. +
    5. Run query's name's permission query algorithm, passing query and status.
    6. - Queue a task on the permissions task source to fire an event named + Queue a task on the permissions task source to fire an event named change at status.
    @@ -1804,7 +1803,7 @@

    Permissions

    - A PermissionStatus object MUST NOT be garbage collected if it has an event listener whose type is change. + A PermissionStatus object MUST NOT be garbage collected if it has an event listener whose type is change.

    @@ -1817,8 +1816,8 @@

    Permissions

    - Two classes of product can claim conformance to this specification: user agents and - other specifications (i.e., a technical report that specifies a powerful feature in a manner that conforms to the requirements of this specification). + Two classes of product can claim conformance to this specification: user agents and + other specifications (i.e., a technical report that specifies a powerful feature in a manner that conforms to the requirements of this specification).

    A. @@ -1831,7 +1830,7 @@

    Permissions

    - On the one hand, this specification exclusively concerns itself with powerful features + On the one hand, this specification exclusively concerns itself with powerful features whose access is managed through a user-agent mediated permissions UI (i.e., permissions where the user gives express consent before that feature can be used, and where the user retains the ability to deny that permission at any time for any reason). These powerful @@ -1839,26 +1838,26 @@

    Permissions

    On the other hand, the Permissions Policy specification allows developers to - selectively enable and disable policy-controlled features through a "permissions policy" (be it a HTTP header or the allow attribute). In that sense, the + selectively enable and disable policy-controlled features through a "permissions policy" (be it a HTTP header or the allow attribute). In that sense, the Permissions Policy subsumes this specification in that Permissions Policy governs whether a feature is available at all, independently of this specification. These policy-controlled features are also registered in the Permissions Registry.

    A powerful feature that has been disabled by the Permissions Policy specification - always has its permission state reflected as "denied" by this specification. This - occurs because reading the current permission - relies on [HTML]'s "allowed to use" check, which itself calls into the + always has its permission state reflected as "denied" by this specification. This + occurs because reading the current permission + relies on [HTML]'s "allowed to use" check, which itself calls into the Permissions Policy specification. Important to note here is the sharing of permission names across both specifications. Both this specification and the Permissions Policy specification rely on other specifications defining the names of the permission and - name, and they are usually named the same thing (e.g., "geolocation" + name, and they are usually named the same thing (e.g., "geolocation" of the Geolocation API, and so on).

    Finally, it's not possible for a powerful feature to ever become "granted" through any means provided by the Permissions Policy specification. The only way that a - powerful feature can be granted is by the user giving express permission or by some user agent policy. + powerful feature can be granted is by the user giving express permission or by some user agent policy.

    B. @@ -1908,35 +1907,35 @@

    Permissions

    1. Let parameters be the parameters argument, converted to an IDL value of - type PermissionSetParameters. If this throws an exception, return an invalid argument error. + type PermissionSetParameters. If this throws an exception, return an invalid argument error.
    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 invalid argument error. + value of rootDesc.name's permission descriptor type. If this throws an exception, return a invalid argument error.
    4. If parameters.state is an inappropriate permission - state for any implementation-defined reason, return a invalid argument error. + state for any implementation-defined reason, return a invalid argument error.
      Note

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

      5. -
    5. Let settings be the current settings object. +
    6. Let settings be the current settings object.
    7. Let targets be a list containing all environment settings objects - whose origin is the same as - the origin of settings. + whose origin is the same as + the origin of settings.
    8. Let tasks be an empty list.
    9. For each environment settings object target in targets:
      1. - Queue a task task on the permissions task source of target's - relevant settings object's global object's - browsing context to perform the following step: + Queue a task task on the permissions 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 @@ -1944,7 +1943,7 @@

          Permissions

        2. -
      2. Append task to tasks. +
      3. Append task to tasks.
      10. @@ -1957,8 +1956,8 @@

      Permissions

      Example 7: Setting a permission via WebDriver

    - To set permission for {name: "midi", sysex: true} of the - current settings object of the session with ID 23 to "granted", the local + To set permission for {name: "midi", sysex: true} of the + current settings object of the session with ID 23 to "granted", the local end would POST to /session/23/permissions with the body: 

    {
@@ -1979,13 +1978,13 @@ 
    Permissions
     
    permission state as an element in creating a "fingerprint"
         corresponding to an end-user. Although an adversary can already determine the state of a
         permission by actually using the API, that often leads to a UI prompt being presented to
-        the end-user (if the permission was not already granted). Even though this
+        the end-user (if the permission was not already granted). Even though this
         API doesn't expose new fingerprinting information to websites, it makes it easier for an
         adversary to have discreet access to this information.
       
    
       
    
         A user agent SHOULD provide a means for the user to review, update, and reset the
-        permission state of powerful features associated with an origin.
+        permission state of powerful features associated with an origin.

    D. @@ -2058,7 +2057,7 @@

    Permissions

    [Notifications]
    Notifications API Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://notifications.spec.whatwg.org/
    [Permissions-Policy]
    - Permissions Policy. Ian Clelland. W3C. 7 December 2022. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/ + Permissions Policy. Ian Clelland. W3C. 7 June 2023. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/
    [permissions-registry]
    Permissions Registry. unofficial. URL: https://w3c.github.io/permissions-registry/
    [RFC2119]
    @@ -2073,11 +2072,11 @@

    Permissions

    G.2 Informative references

    [appmanifest]
    - Web Application Manifest. Marcos Caceres; Kenneth Christiansen; Matt Giuca; Aaron Gustafson; Daniel Murphy; Anssi Kostiainen. W3C. 20 December 2022. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/ + Web Application Manifest. Marcos Caceres; Kenneth Christiansen; Matt Giuca; Aaron Gustafson; Daniel Murphy; Anssi Kostiainen. W3C. 2 May 2023. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/
    [Geolocation]
    Geolocation API. Marcos Caceres; Reilly Grant. W3C. 1 September 2022. W3C Recommendation. URL: https://www.w3.org/TR/geolocation/
    [GETUSERMEDIA]
    - Media Capture and Streams. Cullen Jennings; Bernard Aboba; Jan-Ivar Bruaroey; Henrik Boström; youenn fablet. W3C. 15 December 2022. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediacapture-streams/ + Media Capture and Streams. Cullen Jennings; Bernard Aboba; Jan-Ivar Bruaroey; Henrik Boström; youenn fablet. W3C. 4 May 2023. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediacapture-streams/
    [push-api]
    Push API. Peter Beverloo; Martin Thomson; Marcos Caceres. W3C. 30 June 2022. W3C Working Draft. URL: https://www.w3.org/TR/push-api/
    @@ -3365,4 +3364,4 @@

    Permissions

    +})() \ No newline at end of file

    Chrome
    Opera Android ?
    SafariNo16.4+
    Safari iOS ?