editorial: Formally define a permission revocation algorithm. #297
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
While this change is not big, it modifies a concept we have in the spec, so I'd appreciate some extra pairs of eyes to double-check it all makes sense. |
|
Thanks, I'll wait a bit more for either @reillyeon or @marcoscaceres before merging. |
The "block a permission" algorithm was manipulating a `PermissionDescriptor` instance to change its "permission state" and then release any existing locks. However, the Permissions spec does not actually define a way for other specifications to modify a PermissionDescriptor's permission state. What we want here is to react to a user-triggered change that sets the permission state to "denied". That's what the "permission revocation algorithm" hook in the Permissions spec does, so instead of defining a "block a permission" algorithm define a custom "permission revocation algorithm" instead. Related to w3c#198 -- one of @marcoscaceres' comments is about hooking more of the permissions text directly into the Permissions spec.
rakuco
force-pushed
the
define-permission-revocation-algorithm
branch
from
11dcd60 to
50b0b03
Compare
rakuco
pushed a commit
to rakuco/wake-lock
that referenced
this pull request
Feb 4, 2021
This may have made more sense back when we had a custom `WakeLockPermissionDescriptor`, but even then this felt like implementing a custom permission model for no reason. We are just interested in knowing whether we have permission to request a wake lock from the platform, and we can use the Permission spec's "request permission to use" algorithm for that just fine. One important change is related to checking transient activation: the "obtain a permission" algorithm essentially denied requests when "screen-wake-lock"'s permission state was set to "prompt" AND there was no transient user activation. In general, an API should either always or never be user-activation gated. Given Blink is the only current implementation of this spec and it does not currently gate this API on user activation, the transient user activation check was removed altogether for now. Together with w3c#297, this fixes w3c#187 and fixes w3c#198.
reillyeon
approved these changes
Feb 5, 2021
|
FTR: I've filed a Blink bug to track this spec change in https://bugs.chromium.org/p/chromium/issues/detail?id=1174963 |
rakuco
pushed a commit
to rakuco/wake-lock
that referenced
this pull request
Feb 10, 2021
Especially after w3c#297 ("editorial: Formally define a permission revocation algorithm"), it makes more sense to reference this test from the definition of the "screen-wake-lock" powerful feature, as the test has nothing to do with the permission revocation algorithm.
rakuco
pushed a commit
that referenced
this pull request
Feb 10, 2021
Especially after #297 ("editorial: Formally define a permission revocation algorithm"), it makes more sense to reference this test from the definition of the "screen-wake-lock" powerful feature, as the test has nothing to do with the permission revocation algorithm.
rakuco
pushed a commit
to rakuco/wake-lock
that referenced
this pull request
Mar 2, 2021
This may have made more sense back when we had a custom `WakeLockPermissionDescriptor`, but even then this felt like implementing a custom permission model for no reason. We are just interested in knowing whether we have permission to request a wake lock from the platform, and we can use the Permission spec's "request permission to use" algorithm for that just fine. One important change is related to checking transient activation: the "obtain a permission" algorithm essentially denied requests when "screen-wake-lock"'s permission state was set to "prompt" AND there was no transient user activation. In general, an API should either always or never be user-activation gated. Given Blink is the only current implementation of this spec and it does not currently gate this API on user activation, the transient user activation check was removed altogether for now. Together with w3c#297, this fixes w3c#187 and fixes w3c#198.
rakuco
pushed a commit
to rakuco/wake-lock
that referenced
this pull request
Jun 2, 2021
This may have made more sense back when we had a custom `WakeLockPermissionDescriptor`, but even then this felt like implementing a custom permission model for no reason. We are just interested in knowing whether we have permission to request a wake lock from the platform, and we can use the Permission spec's "request permission to use" algorithm for that just fine. One important change is related to checking transient activation: the "obtain a permission" algorithm essentially denied requests when "screen-wake-lock"'s permission state was set to "prompt" AND there was no transient user activation. In general, an API should either always or never be user-activation gated. Given Blink is the only current implementation of this spec and it does not currently gate this API on user activation, the transient user activation check was removed altogether for now. Together with w3c#297, this fixes w3c#187 and fixes w3c#198.
rakuco
pushed a commit
that referenced
this pull request
Jun 7, 2021
This may have made more sense back when we had a custom `WakeLockPermissionDescriptor`, but even then this felt like implementing a custom permission model for no reason. We are just interested in knowing whether we have permission to request a wake lock from the platform, and we can use the Permission spec's "request permission to use" algorithm for that just fine. One important change is related to checking transient activation: the "obtain a permission" algorithm essentially denied requests when "screen-wake-lock"'s permission state was set to "prompt" AND there was no transient user activation. In general, an API should either always or never be user-activation gated. Given Blink is the only current implementation of this spec and it does not currently gate this API on user activation, the transient user activation check was removed altogether for now. Together with #297, this fixes #187 and fixes #198.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The "block a permission" algorithm was manipulating a
PermissionDescriptorinstance to change its "permission state" and then release any existing
locks. However, the Permissions spec does not actually define a way for
other specifications to modify a PermissionDescriptor's permission state.
What we want here is to react to a user-triggered change that sets the
permission state to "denied". That's what the "permission revocation
algorithm" hook in the Permissions spec does, so instead of defining a
"block a permission" algorithm define a custom "permission revocation
algorithm" instead.
Related to #198 -- one of @marcoscaceres' comments is about hooking more of
the permissions text directly into the Permissions spec.
Preview | Diff