- From: Marcos Cáceres via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Sep 2022 05:01:21 +0000
- To: public-device-apis-log@w3.org
@rakuco wrote: >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 https://github.com/w3c/screen-wake-lock/pull/299, for example. Not exactly. This is just a defensive design strategy in case we need to reject the promise in the future for some reason. > 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. (As a followup...) It is. I think we should update `release()` to better reflect this. It should resolve the promise immediately if the ActiveLocks is not empty, but then should actually try to release at the OS level and then settle the final promise. Otherwise this could be racy. -- GitHub Notification of comment by marcoscaceres Please view or discuss this issue at https://github.com/w3c/screen-wake-lock/pull/326#issuecomment-1260390009 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 September 2022 05:01:22 UTC