diff --git a/notifications.bs b/notifications.bs index 5686bd6..43ec345 100644 --- a/notifications.bs +++ b/notifications.bs @@ -291,40 +291,21 @@ removed from the list of notifications. "notification center" (if available). -

Permission model

- -

Notifications can only be displayed if the -user (or user agent on behalf of the user) has granted permission. -The permission to show notifications -for a given origin is one of three strings: - -

-
"default" -

This is equivalent to "denied", but the user has made no - explicit choice thus far. - -

"denied" -

This means the user does not want - notifications. +

Permissions integration

-
"granted" -

This means notifications can be - displayed. -

+

The Notifications API is a powerful feature which is identified by the +name "{{PermissionName/notifications}}". [[!Permissions]] -

There is no equivalent to "default" -meaning "granted". In that case -"granted" is simply returned as there would be no reason -for the application to ask for permission. +

To get the notifications permission state, run these steps: -

Permissions integration

+
    +

  1. Let permissionState be the result of getting the current permission state + with "{{PermissionName/notifications}}". -

    The Notifications API is a powerful feature which is identified by the string -"notifications" and has its allowed in non-secure contexts flag set. -[[!Permissions]] +

  2. If permissionState is "prompt", then return "default". -

    This specification's "default" permission -state maps to the [=permission/prompt=] permission state in the Permissions API. +

  3. Return permissionState. +

Direction

@@ -721,9 +702,9 @@ constructor steps are:

Run these steps in parallel:

    -

  1. If permission for notification's origin is not - "granted", then queue a task to fire an event named error - on this, and abort these steps. +

  2. If the result of getting the notifications permission state is not + "granted", then queue a task to fire an event named + error on this, and abort these steps.

  3. Run the fetch steps for notification. @@ -735,8 +716,7 @@ constructor steps are:

    Static members

    The static permission getter steps are to -return the permission for the current settings object's -origin. +return the result of getting the notifications permission state.

    If you edit standards please refrain from copying the above. Synchronous permissions are like @@ -760,27 +740,14 @@ method steps are:

    1. Let global be the current global object. -

    2. Let permissionDescriptor be the {{PermissionDescriptor}} with - {{PermissionDescriptor/name}} set to "notifications". - -

    3. Let permissionStatus be the result of - creating a `PermissionStatus` for - permissionDescriptor. -

    4. Let promise be a new promise in this's relevant Realm.

    5. Run these steps in parallel:

        -

      1. Run the permission query algorithm with - permissionDescriptor and permissionStatus. - -

      2. Let permissionState be permissionStatus's - {{PermissionStatus/state}}. - -

      3. If permissionState is {{PermissionState/"prompt"}}, then set - permissionState to "default". +

      4. Let permissionState be the result of + requesting permission to use "{{PermissionName/notifications}}".

      5. Queue a global task on the DOM manipulation task source given global @@ -1083,7 +1050,7 @@ method steps are:

        Run these steps in parallel:

          -

        1. If permission for notification's origin is not +

        2. If the result of getting the notifications permission state is not "granted", then queue a global task on the DOM manipulation task source given global to reject promise with a {{TypeError}}, and abort these steps.