- From: Thomas Steiner via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Sep 2019 07:06:53 +0000
- To: public-device-apis-log@w3.org
I tried to rewrite my example from https://github.com/w3c/wake-lock/issues/226#issue-477803265 with the new new new API proposal: ```js (async () => { let lock = null; try { lock = await navigator.wakeLock.request('screen'); console.log('Wake Lock is active'); // This would fire on visibility changes lock.addEventListener('statechange', async (e) => { // Re-request a new lock after a visibility change lock = await navigator.wakeLock.request('screen'); // (♲) }); // Schedule a regular release window.setTimeout(() => { lock.release(); lock = null; // (←) }, 5000); } catch (e) { // This would catch browser interventions // like battery saver force-releasing the wake lock console.error(e.name, e.message); lock = null; // (←) } })(); ``` Two and a half questions: - Would `onstatechange` fire in case of a browser intervention (that would be `catch`'ed (ugh, well, caught))? - As the only state change that's possible is 'active' to 'released', maybe `onstatechange` could be renamed to `onrelease`? - Not entirely sure about garbage collection here. If I `null`-ify the `lock` variable (above marked with ` // (←)`), would it's event listeners be GC'ed? And if I recycle the variable to re-acquire a new lock (above marked with ` // (♲)`), would a previously created event listener be still there? -- GitHub Notification of comment by tomayac Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/226#issuecomment-533982302 using your GitHub account
Received on Monday, 23 September 2019 07:06:54 UTC