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 8 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
206 changes: 60 additions & 146 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,6 @@
xref: {
profile: "web-platform",
specs: [
"permissions",
"permissions-policy",
]
}
Expand Down Expand Up @@ -162,63 +161,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 @@ -309,11 +251,19 @@ <h3>
The <dfn>request()</dfn> method
</h3>
<p data-tests="wakelock-type.https.any.html">
The <code>request(|type:WakeLockType|)</code> method steps are:
The `request(|type:WakeLockType|)` method steps are:
Copy link
Member

Choose a reason for hiding this comment

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

ReSpec doesn't seem to like this change. request(|type:WakeLockType|) is being written literally like that in the page.

</p>
<ol class="algorithm">
<li>Let |document:Document| be [=this=]'s [=relevant global
object=]'s [=associated Document=].
object=]'s [=associated `Document`=].
Copy link
Member

Choose a reason for hiding this comment

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

The change in the order of steps here looks unrelated. They might even make sense, but I'd rather do this in another PR.

</li>
<li>If the |document|'s [=Document/browsing context=] is `null`,
return [=a promise rejected with=] {{"NotAllowedError"}}
{{DOMException}}.
</li>
<li data-tests="wakelock-active-document.https.window.html">If
|document| is not [=Document/fully active=], return [=a promise
rejected with=] with a {{"NotAllowedError"}} {{DOMException}}.
</li>
<li data-tests="wakelock-disabled-by-feature-policy.https.sub.html">
If |document| is not [=allowed to use=] the [=policy-controlled
Expand All @@ -325,80 +275,33 @@ <h3>
|document|, return [=a promise rejected with=] a
{{"NotAllowedError"}} {{DOMException}}.
</li>
<li>If the |document|'s [=Document/browsing context=] is `null`,
return [=a promise rejected with=] {{"NotAllowedError"}}
{{DOMException}}.
</li>
<li data-tests="wakelock-active-document.https.window.html">If
|document| is not [=Document/fully active=], return [=a promise
rejected with=] with a {{"NotAllowedError"}} {{DOMException}}.
</li>
<li data-tests="wakelock-document-hidden-manual.https.html">If
|document|'s [=Document/visibility state=] is "`hidden`", return [=a
promise rejected with=] {{"NotAllowedError"}} {{DOMException}}.
</li>
<li>Let |promise:Promise| be [=a new promise=].
</li>
<li>Run the following steps <a>in parallel</a>:
<li>[=In parallel=]:
Copy link
Member

Choose a reason for hiding this comment

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

Was there a particular reason to change the original version? It's just saying the same thing.

Copy link
Member Author

Choose a reason for hiding this comment

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

Just reads better.

<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>Attempt to [=acquire a wake lock=] of type
Copy link
Member

Choose a reason for hiding this comment

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

The steps still look weird:

  • The check for whether document.[[ActiveLocks]]["screen"] is empty was dropped.
  • Only acquiring the wake lock happened in parallel, document.[[ActiveLocks]] was only read and manipulated from the the main thread to avoid races, but now all these steps are happening in parallel.

{{WakeLockType/"screen"}}.
<aside class="note">
The <a>acquire a wake lock</a> algorithm may ultimately be
unable to acquire a lock from the operating system, but this
is indistinguishable from a successful lock acquisition to
avoid exposing private information about the underlying
system's state (failure to acquire a lock could indicate low
battery levels, for example).
</aside>
</li>
<li data-tests="wakelock-request-denied.https.html">If |state| is
{{PermissionState/"denied"}}, then:
<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>
<li>Abort these steps.
</li>
</ol>
<li>Let |lock:WakeLockSentinel| be a newly created
{{WakeLockSentinel}} instance with its {{WakeLockSentinel/type}}
attribute set to |type|.
</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:
<ol>
<li>If |document|'s [=Document/visibility state=] is
"`hidden`", then:
<ol>
<li>Reject |promise| with a {{"NotAllowedError"}}
{{DOMException}}.
</li>
<li>Abort these steps.
</li>
</ol>
</li>
<li>If |document|.{{Document/[[ActiveLocks]]}}["`screen`"]
[=list/is empty=], then invoke the following steps <a>in
parallel</a>:
<ol>
<li>Invoke <a>acquire a wake lock</a> with
{{WakeLockType/"screen"}}.
<aside class="note">
The <a>acquire a wake lock</a> algorithm may
ultimately be unable to acquire a lock from the
operating system, but this is indistinguishable from
a successful lock acquisition to avoid user
fingerprinting (failure to acquire a lock can
indicate low battery levels, for example).
</aside>
</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>[=List/Append=] |lock| to
|document|.{{Document/[[ActiveLocks]]}}["`screen`"].
</li>
<li>[=Queue a global task=] to [=resolve=] |promise| with |lock|.
</li>
</ol>
</li>
Expand Down Expand Up @@ -598,8 +501,8 @@ <h2>
MUST treat wake lock acquisition as <strong>advisory-only</strong>.
</p>
<p>
Conversely, the <a>user agent</a> <dfn data-lt=
"release wake lock">releases the wake lock</dfn> by requesting the
Conversely, the <a>user agent</a> can <dfn data-lt=
"releases the wake lock">release the wake lock</dfn> by requesting the
underlying operating system to no longer apply the wake lock. The lock
is considered released only when the request to the operating system
succeeds.
Expand Down Expand Up @@ -721,32 +624,27 @@ <h3>
<li>Remove |lock| from
|document|.{{Document/[[ActiveLocks]]}}[|type|].
</li>
<li>[=Queue a task=] on the [=screen wake lock task source=] to:
Copy link
Member

Choose a reason for hiding this comment

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

The changes to this section also look unrelated to permissions and should be sent in a separate PR.

<ol>
<li>Set |lock|'s {{WakeLockSentinel/[[Released]]}} to `true`.
</li>
<li>[=Fire an event=] named "`release`" at |lock|.
</li>
</ol>
</li>
<li>If |document|.{{Document/[[ActiveLocks]]}}[|type|] [=list/is
empty=], then run the following steps <a>in parallel</a>:
<ol>
<li>Ask the underlying operating system to release the wake lock
of type |type| and let |success:boolean| be `true` if the
operation succeeded, or else `false`.
</li>
<li>If |success| is `true` and |type| is `"screen"` run the
following:
<ol>
<li>Reset the platform-specific inactivity timer after which
<li>Ask the underlying operating system to [=release the wake lock=].</li>
<li>If the operation succeeds, reset the platform-specific inactivity timer after which
the screen is actually turned off.
</li>
</ol>
<aside class="note">
Resetting the inactivity timer prevents the screen from going
blank immediately after the wake lock is released.
</aside>
</li>
<aside class="note">
Resetting the inactivity timer prevents the screen from going
blank immediately after the wake lock is released.
</aside>
</ol>
</li>
<li>Set |lock|'s {{WakeLockSentinel/[[Released]]}} to `true`.
</li>
<li>
<a>Fire an event</a> named "`release`" at |lock|.
</li>
</ol>
</section>
</section>
Expand Down Expand Up @@ -777,6 +675,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