W3C home > Mailing lists > Public > public-device-apis-log@w3.org > August 2021

Re: [screen-wake-lock] WakeLock and Page Life Cycle (#139)

From: Raphael Kubo da Costa via GitHub <sysbot+gh@w3.org>
Date: Fri, 20 Aug 2021 10:41:11 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-902603583-1629456069-sysbot+gh@w3.org>
> Would this be the same as the document becoming non-fully active?

It's not entirely clear to be, to be honest. The definition of "fully active document" in HTML isn't very easy to understand, and the Page Lifecycle spec does not seem to explain how well it interacts with that concept, but adds a few other ones ("frozen" and "discarded") that _seem_ to precede loss of full activity. OTOH, there doesn't seem to be an explicit hook in HTML for "run these algorithms when the document is no longer fully active", so in Chromium we just run it in `ContextDestroyed()` which, AFAIU, runs when the browsing context is about to be destroyed.

In addition to wicg/page-lifecycle#31, wicg/page-lifecycle#7 also mentions Wake Lock integration, as it's not entirely clear to me how page visibility, page lifecycle and wake locks are supposed to interact (and the order that's supposed to happen).
> I think the "[handling document loss of full activity](https://w3c.github.io/screen-wake-lock/#handling-document-loss-of-full-activity)" might be wrong at the moment... paraphrasing the spec:
> 1. if the document is no longer fully active, [release the wake lock](https://w3c.github.io/screen-wake-lock/#ref-for-dfn-release-a-wake-lock-5).
> 2. Ask the OS to release the lock.
> 3. firecracker Fire an event named "release".
> Shouldn't step 3 wait for the document to become fully active again before firing the event?

Is it possible for a document to be come fully active again (emphasis on again)? My understanding is that the document is no longer fully active when the browsing context is destroyed, in which case there'd be no state to go back to in the first place.

There's also the bfcache case which is kind of related to the page visibility + page lifecycle + wake lock integration I mentioned above. I remember there was a discussion in Chromium a while ago about whether pages holding wake locks would be eligible for bfcache, but in the end the locks are always supposed to be released when the page becomes hidden and before the bfcache checks anyway.

> (also, fire the event should probably be queued... we might want to separate "release the lock" from the actual "release" event being fired). CC @rakuco.

Well, this was what prompted the long discussions in #293 and #299 in the first place :-) The conclusion back then was that there was no benefit in queuing rather than firing the event directly.

GitHub Notification of comment by rakuco
Please view or discuss this issue at https://github.com/w3c/screen-wake-lock/issues/139#issuecomment-902603583 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 20 August 2021 10:41:13 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:59 UTC