Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove permission check #326

Closed
wants to merge 10 commits into from
Closed

Remove permission check #326

Changes from 5 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
3b695c2
Remove permission check
marcoscaceres Sep 9, 2021
f70fd9e
Review feedback
marcoscaceres Sep 30, 2021
0972342
fixup markup
marcoscaceres Sep 30, 2021
04d0d22
Merge branch 'gh-pages' into permissions
marcoscaceres Sep 27, 2022
b455083
Update index.html
marcoscaceres Sep 27, 2022
0b3b13c
Update index.html
marcoscaceres Sep 27, 2022
3152f77
Update index.html
marcoscaceres Sep 27, 2022
a94e74d
Update index.html
marcoscaceres Sep 28, 2022
f521b67
Update index.html
marcoscaceres Sep 28, 2022
bcb1470
fix markup
marcoscaceres Sep 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 36 additions & 73 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@
xref: {
profile: "web-platform",
specs: [
"permissions",
"page-visibility",
marcoscaceres marked this conversation as resolved.
Show resolved Hide resolved
marcoscaceres marked this conversation as resolved.
Show resolved Hide resolved
"permissions-policy",
]
}
Expand Down Expand Up @@ -162,63 +162,6 @@ <h3>
</p>
</aside>
</section>
<section>
<h3>
Permissions and user prompts
</h3>
<p>
The [[PERMISSIONS]] API provides a uniform way for websites to request
permissions from users and query which permissions they have.
</p>
<p>
A <a>user agent</a> can <dfn data-lt=
"deny wake lock|denies the wake lock">deny a wake lock</dfn> of a
particular <a>wake lock type</a> for a particular {{Document}} by any
implementation-specific reason, such as platform setting or user
preference.
</p>
<p>
It is RECOMMENDED that a user agent show some form of unobtrusive
notification that informs the user when a wake lock is active, as well
as provides the user with the means to [=screen wake lock permission
revocation algorithm|block=] the ongoing operation, or simply dismiss
the notification.
reillyeon marked this conversation as resolved.
Show resolved Hide resolved
</p>
<section>
<h2>
The `"screen-wake-lock"` powerful feature
marcoscaceres marked this conversation as resolved.
Show resolved Hide resolved
</h2>
<p data-tests="wakelockpermissiondescriptor.https.html">
The `"screen-wake-lock"` <a>powerful feature</a> enables the
capability defined by this specification.
</p>
</section>
<section>
<h2>
Permission algorithms
</h2>
<p>
The `"screen-wake-lock"` <a>powerful feature</a> defines a [=powerful
feature/permission revocation algorithm=]. To invoke the <dfn>Screen
Wake Lock permission revocation algorithm</dfn>, run these steps:
</p>
<ol class="algorithm">
<li>Let |document:Document| be the [=current global object=]'s
[=associated Document=].
</li>
<li>Let |lockList| be
|document|.{{Document/[[ActiveLocks]]}}["`screen`"].
</li>
<li>[=list/For each=] |lock:WakeLockSentinel| in |lockList|:
<ol>
<li>Run <a>release a wake lock</a> with |document|, |lock|, and
{{WakeLockType/"screen"}}.
</li>
</ol>
</li>
</ol>
</section>
</section>
<section>
<h3>
Concepts
Expand Down Expand Up @@ -339,28 +282,23 @@ <h3>
</li>
<li>Let |promise:Promise| be [=a new promise=].
</li>
<li>Run the following steps <a>in parallel</a>:
<li>
<a>Queue a global task</a> on the <a>screen wake lock task
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need to queue a global task here? We're already in the main thread at this point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't technically need to but this provides implementations with the freedom to not return a settled Promise synchronously from this method, as otherwise this method doesn't need to be Promise-returning at all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as otherwise this method doesn't need to be Promise-returning at all.

Wouldn't this be a case of "we thought there should be async stuff happening, now there's not but we can't break backwards compatibility"? It's how we ended up with WakeLockSentinel.release() returning a resolved promise after #299, for example.

I'm not saying I'm in favor of doing that, at this point I'm more curious about whether this is standard practice, or even if I'm looking at it from the wrong perspective.

source</a> given |document|'s <a>relevant global object</a> to run
these steps:
<ol>
<li>Let |state:PermissionState| be the result of <a>requesting
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without these steps, I think you can drop the "run the following steps in parallel above", as all the remaining sub-steps are run from a queued global task.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good suggestion!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Acquiring the lock needs to happen in parallel.

permission to use</a> "`screen-wake-lock`".
</li>
<li data-tests="wakelock-request-denied.https.html">If |state| is
{{PermissionState/"denied"}}, then:
<li>If |document|'s [=visibility state=] is "hidden", then:
marcoscaceres marked this conversation as resolved.
Show resolved Hide resolved
<ol>
<li>
<a>Queue a global task</a> on the <a>screen wake lock task
source</a> given |document|'s <a>relevant global object</a>
to reject |promise| with a {{"NotAllowedError"}}
{{DOMException}}.
<li>Reject |promise| with a {{"NotAllowedError"}}
{{DOMException}}.
</li>
<li>Abort these steps.
</li>
</ol>
</li>
<li>
<a>Queue a global task</a> on the <a>screen wake lock task
source</a> given |document|'s <a>relevant global object</a> to
run these steps:
<li>If |document|.{{Document/[[ActiveLocks]]}}["`screen`"]
[=list/is empty=], then invoke the following steps <a>in
parallel</a>:
<ol>
<li>If |document|'s [=Document/visibility state=] is
"`hidden`", then:
Expand Down Expand Up @@ -400,6 +338,15 @@ <h3>
</li>
</ol>
</li>
<li>Let |lock:WakeLockSentinel| be a new {{WakeLockSentinel}}
object with its {{WakeLockSentinel/type}} attribute set to
|type|.
</li>
<li>[=List/Append=] |lock| to
|document|.{{Document/[[ActiveLocks]]}}["`screen`"].
</li>
<li>Resolve |promise| with |lock|.
</li>
</ol>
</li>
<li>Return |promise|.
Expand Down Expand Up @@ -777,6 +724,22 @@ <h2>
application is having a negative energy impact on the device, and allow
them to take action if so desired.
</p>
<p>
A <a>user agent</a> MAY <dfn data-lt=
"deny wake lock|denies the wake lock">deny a wake lock</dfn> of a
particular <a>wake lock type</a> for a particular {{Document}} by any
implementation-specific reason, such as platform setting or user
preference.
</p>
<aside class="issue" data-number="324" data-cite="permissions">
<p>
Together with implementers, the Working Group is still evaluating if
this API will be classed as a [=powerful feature=]. Initial
implementations have thus far not required express permission via a
UI prompt to request a screen wake lock. This might change as we gain
more implementation experience and receive more user feedback.
</p>
</aside>
marcoscaceres marked this conversation as resolved.
Show resolved Hide resolved
</section>
<section id="examples" class="informative">
<h2>
Expand Down