[wake-lock] Handling WakeLock.request() promises in parallel steps (#222)

rakuco has just created a new issue for https://github.com/w3c/wake-lock:

== Handling WakeLock.request() promises in parallel steps ==
As of 0e75758fde9d4e87c3fc3706cd90131c2ae6d927, the WakeLock.request() algorithm says:

> 5. [handle AbortSignal]
> 6. Run the following steps in parallel, but abort when options' signal member is present and its aborted flag is set:
> 6.1. Let state be the result of awaiting obtain permission steps with type:
> 6.1.1 If state is "denied", then reject promise with a "NotAllowedError" DOMException, and abort these steps.
> 6.2. Let success be the result of awaiting acquire a wake lock with promise and type:
> 6.2.1. If success is false then reject promise with a "NotAllowedError" DOMException, and abort these steps.
> 7. Return promise

Since step 6 is run in parallel, there is a short window where  `promise` is accessible to users and step 6.2 has not been called yet (and thus `promise` is not in `[[ActiveLocks]]`).

As such, algorithms that act on `[[ActiveLocks]]` such as https://w3c.github.io/wake-lock/#handling-document-loss-of-full-activity and https://w3c.github.io/wake-lock/#handling-document-loss-of-visibility will not affect `promise` because it is not in `[[ActiveLocks]]`, and we end up trying to acquire a lock anyway.

Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/222 using your GitHub account

Received on Friday, 14 June 2019 11:49:27 UTC