W3C home > Mailing lists > Public > public-device-apis-log@w3.org > April 2019

Re: [wake-lock] Canceling using AbortSignal is a bit weird (#171)

From: Reilly Grant via GitHub <sysbot+gh@w3.org>
Date: Mon, 01 Apr 2019 20:30:39 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-478735593-1554150635-sysbot+gh@w3.org>
Given the behavior we really want is being able to release a wake lock after it has been acquired I agree that the use of `AbortSignal` is a little odd. When it comes to the state of a particular `WakeLock` instance I think adding a `release()` method that potentially aborts a `request()` call makes sense.

Some potential solutions for releasing wake locks when you don't have a reference to the original `WakeLock` instance:

1. A wake lock is automatically released when it is garbage collected.
2. A wake lock cannot be released if it has been garbage collected. That is, losing track of your `WakeLock` instances is a programming error.
3. A static `WakeLock.releaseAll()` method will release all wake locks of a given type.
4. A static `WakeLock.getAll()` method will return all active `WakeLock` instances.

Option (4) offers another interesting possibility which is naming wake locks. This could be useful for debugging purposes when a page includes many libraries that could have acquired a wake lock.

GitHub Notification of comment by reillyeon
Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/171#issuecomment-478735593 using your GitHub account
Received on Monday, 1 April 2019 20:30:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 1 April 2019 20:30:40 UTC