- From: Reilly Grant via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Jun 2020 20:31:55 +0000
- To: public-device-apis-log@w3.org
I think we can find other examples where a system wake lock is desirable that Mozilla won't find objectionable. The two that come to mind immediately are: * Ensuring that data is written to local or cloud storage before the system goes into a low power mode. * Performing local processing (think Squoosh or WeVideo) which would be interrupted if the system went to sleep. The fact that developers have built workarounds for this that abuse wake locks taken incidentally to other APIs is an indication of the value of this capability however this means that the user agent is no longer able to deduce the developer's intention from the behavior of their code, leading to the complex anti-abuse mechanisms that @mounirlamouri discussed. I believe that providing an API to explicitly request these locks and express that intent will allow user agents to better control against these behaviors. For example, at TPAC2019 I proposed that to acquire a system wake lock the application must be able to express the progress of the operation that it is performing that needs this lock. The user agent could display a notification indicating this progress and provide the user with a "stop" button which would release the lock and signal to the application that it should abort. To avoid abuse the user agent could debounce these notifications so that short tasks do not show one at all (after all, if the tasks runs more quickly than the system takes to enter a low power state then there was no need to take a wake lock at all) and to prevent the application from attempting to hide the notification by making it disappear quickly. -- GitHub Notification of comment by reillyeon Please view or discuss this issue at https://github.com/w3c/screen-wake-lock/issues/232#issuecomment-639100499 using your GitHub account
Received on Thursday, 4 June 2020 20:31:57 UTC