W3C home > Mailing lists > Public > public-device-apis-log@w3.org > December 2018

[wake-lock] Give advice on how UAs should infer consent to take a wakelock (#140)

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Thu, 13 Dec 2018 22:31:17 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-390889216-1544740276-sysbot+gh@w3.org>
jyasskin has just created a new issue for https://github.com/w3c/wake-lock:

== Give advice on how UAs should infer consent to take a wakelock ==
The spec currently [says](https://w3c.github.io/wake-lock/#dfn-deny-wake-lock)

> A user agent MAY check user settings or request user permission in order to decide whether it will deny wake lock of a particular type for a particular Document.

I think that's the appropriate normative language, but it'd help align expectations between UAs and authors if the document gave some advice about how the UA will make sure the user isn't surprised and unhappy about how their device behaves.

Some options:

* Pop up a permission dialog each time any kind of wake lock is requested. (Ick)
* Show a notification while any wake lock is active, and have the notification offer a way to release the wake lock. (I.e. "ask for forgiveness", like fullscreen)
* Only do the above for "system" wake locks, since "screen" locks are easier to notice and manually disable.
* Show a permission dialog if the "system" wake lock is used from a site with other permissions that users might not want used in the background.
* Just let sites do whatever.

I'm sure folks will think of other good options in the replies.

Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/140 using your GitHub account
Received on Thursday, 13 December 2018 22:31:19 UTC

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