[webkit-dev] WebKit position on Wake Lock API

Thomas Steiner tomac at google.com
Thu Feb 20 02:12:41 PST 2020

Hi Ryosuke, all,

I'm still soliciting a feedback.


For now, I can say we're very much concerned about any impact on battery
> life since that's no.1 thing our users care about. Since even a few
> percentage point of battery life regression would be a major concern, there *needs
> to be extraordinarily good reasons* to add this API;

As pointed out earlier, there is a workaround of playing an invisible video
to keep the screen awake, and people are (ab)using it:

This proposed API could be a proper way of having this feature, allowing
user agents to display appropriate indications (see
my ideas).

Since the screen is visibly on, the impact on battery life is very
tangible; since there's no hidden background activity or anything that an
app couldn't do anyways. Actually, iOS has started to show (add to home
screen) Web.app activity in the Battery stats, so users can even trace
battery consumption back to web apps.

> I just don't think any of the use cases listed in
> https://w3c.github.io/wake-lock/#introduction are compelling enough to
> meet such a standard.

Looking at the _screen_ wake lock use cases:

* Use turn-by-turn navigation while walking and driving and not interacting
with the phone.
Apple/Google Maps do that and need that on native. Both web apps could use
this as well (Apple Maps is available on the web
https://goo.gle/apple-hq-on-apple-maps, navigation isn't, but here's a
navigation link for Google Maps:

* Allow an external device to read a boarding card with a barcode on a
Starbucks have publicly requested this feature (combined with the
capability to boost the screen brightness to the maximum brightness:
https://github.com/w3c/wake-lock/issues/129#issuecomment-439713499). Their
PWA is used by many of their customers.

* Showing a presentation where each slide is shown for a prolonged period.
Google Slides has this challenge.

I'm biased, but all of those sound compelling to me.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200220/7f6e247a/attachment.htm>

More information about the webkit-dev mailing list