[screen-wake-lock] "Release a wake lock": should we queue a task to fire the "release" event? (#293)

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

== "Release a wake lock": should we queue a task to fire the "release" event? ==
(also related: #139)

I've been reviewing a [Chromium CL](https://chromium-review.googlesource.com/c/chromium/src/+/2599854) that deals with bfcache, and ended up with a few questions about our ["release a wake lock"](https://w3c.github.io/screen-wake-lock/#dfn-release-a-wake-lock) algorithm and its relationship with the Page Lifecycle API and bfcache.

Since #242, the "release a wake lock" algorithm queues a task to fire the "release" event (and, since #279, to set the `[[Released]]` internal slot to `true`). The question is whether this should be done in a task or as a synchronous step in the algorithm.

In the Chromium CL in question, we've noticed that when navigating away from a page, we do reach https://w3c.github.io/screen-wake-lock/#handling-document-loss-of-visibility, the "release a wake lock" algorithm does run but the queued task is never run, as the page is frozen first (even without bfcache, in which case I guess it'd be unloaded first).

Queuing a task to fire an event [seems idiomatic](https://w3ctag.github.io/design-principles/#guard-against-recursion), but in this case I wonder if it's the best choice, especially since this happens when the document both loses visibility and loses full activity. Or, at the very least, I wonder if changing the `[[Released]]` slot should be done synchronously, or if doing that separately from firing the event makes even less sense.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 1 February 2021 15:08:53 UTC