The changes added in #123 have introduced some behavior changes to the two
requestPermission() operations that were not originally intended.
Although the original steps were heavily modeled after the WebKit
implementation and do not follow what other specifications normally do, some
behavior changes from #123 have not been discussed and have been made more
backwards-compatible:
Calls to "request permission to use" may return "prompt", while the
previous version implicitly converted anything that was not "granted" to
"denied" (possibly because the current Safari implementation shows a modal
dialog asking for access, so users can only allow or deny the permission
request, so remaining at the "prompt" state is not possible).
From a specification perspective, if a user has not explicitly granted the
permission request, "prompt" is essentially the same as "denied" anyway,
so we now explicitly set anything that is not "granted" to "denied" again.
The previous steps only checked for transient activation if users had not
made an explicit permission choice yet, which basically means that the
permission state is set to "prompt".
This change restores this behavior by first checking the current
permission states for all required permission names and only throwing a
NotAllowed exception if one of them is "prompt" and there is no transient
activation. In other words, if a permission is either "granted" or
"denied" then requestPermission() will resolve to one of the values
without requiring transient activation.
While here, refer to the right definitions of "granted" and "denied": use
the PermissionState enum definitions, which is what the Permissions API
algorithms we invoke return, rather than the non-Web IDL definitions that
these enum values correspond to.
The changes added in #123 have introduced some behavior changes to the two requestPermission() operations that were not originally intended.
Although the original steps were heavily modeled after the WebKit implementation and do not follow what other specifications normally do, some behavior changes from #123 have not been discussed and have been made more backwards-compatible:
While here, refer to the right definitions of "granted" and "denied": use the PermissionState enum definitions, which is what the Permissions API algorithms we invoke return, rather than the non-Web IDL definitions that these enum values correspond to.
Preview | Diff