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.

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

Remove permission check #326

Closed
wants to merge 10 commits into from
Closed
Changes from 6 commits
Commits
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
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 [=Document/visibility state=] is "hidden", then:
Copy link
Member

Choose a reason for hiding this comment

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

Something went wrong with the merge in these steps too: all the main substeps within the "Queue a global task" step have been duplicated inside the If document.[[ActiveLocks]]["screen"] is empty substep (see the Preview link).

<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