- From: Reilly Grant via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Oct 2019 23:04:22 +0000
- To: public-device-apis-log@w3.org
> * A `WakeLockEvent`'s only attribute is `lock`, which is a `WakeLockSentinel`. If we've reached a "release" event handler with a `WakeLockEvent`, calling `release()` on it will either do nothing or return a rejected promise based on the above. In other words `lock` is essentially useless in a `WakeLockEvent` except for its `type` attribute. In this case, wouldn't it suffice to have a `type` attribute in `WakeLockEvent` to do something like
> ```js
> lock.addEventListener('release', ev => { lock = navigator.wakeLock.request(ev.type); })
> ```
Providing the `WakeLockSentinel` rather than the `WakeLockType` prevents duplication of attributes between `WakeLockSentinel` and `WakeLockEvent`. It also allows script to know exactly which sentinel has been invalidated. At the moment that can be trivially deduced from the `WakeLockType` but this avoids potential ambiguity going forward.
> * Is the "release" event supposed to indicate that a particular `WakeLockSentinel` has been released or that the platform wake lock has been released? In other words, if I create two screen wake locks and call `release()` on one, should it instantly receive a "release" event or does that happen only when both locks are released and we thus no longer hold a platform wake lock?
It indicates a particular `WakeLockSentinel` has been released. If you create two wake locks and `release()` one then only that one will receive a "release" event. If the wake lock is released by the platform then both will receive a "release" event.
--
GitHub Notification of comment by reillyeon
Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/226#issuecomment-538586836 using your GitHub account
Received on Friday, 4 October 2019 23:04:24 UTC