Re: [whatwg] Proposal: Wake Lock API


Would it make sense to tie the system lock to a notification?

For example:

new Notification("Processing...", {tag: "abc", progressBar: 0.8, 
wakeLock: "system"});

There are many myths and rumors about how to conserve battery on mobile 
devices. A small improvement could be to require apps to show some kind 
of UI whenever they are allowed to consume resources in the background.

Jesper Kristensen

Den 14-08-2014 kl. 03:00 skrev Jonas Sicking:
> On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres <> wrote:
>> On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
>>> On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
>>>> I don't have a strong opinion. My concern was mostly about developers
>>>> having to watch for a whole bunch of different interaction queues (touch
>>>> events, mouse events, focus events, orientation-change events, etc.) in
>>>> order to release the lock at the right time.
>>> Do you have specific UC? The basic UC I have in mind (reading a book,
>>> watching a video, playing a game) would not use a timeout.
>> Yes, Google Play Books will wait five minutes from the last interaction to turn off the screen. This is nice if you fall a sleep while reading and long enough for a user to read a page without having the screen dim.
>> See:
>> I was trying to model that problem with the API.
>>>> Question remains if there are other kinds of locks that we might need.
>>>> For example, Firefox OS has "wifi" as a lock type. I'm assuming that
>>>> their model keeps the "cpu" on, but the device can still shut down the
>>>> radios on a device. In the proposal, we lump "wifi" and "cpu" into
>>>> "system".
>>> Why not breaking these in different sub-systems? I can definitely
>>> imagine my phone having the CPU kept at 100% while the screen is off if
>>> it requires to do a heavy computation. Forcing the screen to stay on
>>> while doing that would be a waste of battery.
>> Sorry, I was trying to say exactly what you said above. No need to keep the screen on when using "system", obviously.
>> Ideally, we could do something like:
>> "display" = keep display on + system/cpu + network
>> "network" (wifi/cell) = system/cpu + network (screen off)
>> "system" = just cpu, turn off screen and radio.
>> Hopefully, something like that means you don't need to pick an choose amongst numerous options.
> I think the locks are fairly orthogonal.
> Holding the "display" lock just prevents the normal "turn off device
> because user hasn't interacted with it for X minutes" timer from
> firing. I.e. while the display lock is held, the screen won't
> automatically time out and put the device to sleep.
> However if the user presses the "power" button the screen would still
> turn off and the device would still go to sleep.
> Holding the "system" lock however wouldn't prevent the screen from
> turning off. But it would prevent the CPU from going to sleep even if
> the screen times out or if the user presses the power button.
> Holding both "display" and "system" means that the screen won't time
> out. If the user presses the power button the screen would turn off
> but the CPU would still not be put to sleep.
> So I think it makes sense to expose an array of which locks the page
> holds since all combinations of the "system" and "display" locks yield
> different behavior.
> I am however more worried about that only having a request() and a
> release() function means that pages that contain multiple independent
> subsystems will have to make sure that they don't stomp on each
> other's locks. Simply counting request() calls vs. release() calls
> helps, but doesn't fully solve the problem. It's very easy to
> accidentally call release too many times, in response to some UI
> action for example.
> An alternative design would be something like
> x = new WakeLock("display");
> x.request();
> x.release();
> Extra calls of either request() or release() are ignored, but pages
> can create any number of WakeLocks of the same type.
> Regarding timeouts, the use case that I've come across many times is
> pages that contain a lot of text, or some form of puzzle. In those
> cases you don't want to completely disable the screen timeout. But you
> might want to set it to some larger large value, say 15 minutes.
> It's somewhat hard to work around the lack of a timeout. What you
> could do is to release the lock after 15 minutes, but then that means
> that the normal screen timer kicks in, which adds an unknown number of
> minutes of the screen being on.
> If you instead were able to create a "display" lock with a 15 minute
> timeout, the platform could use the longest value of 15 minutes and
> the platform screen timeout.
> And note that you in normal use cases *do* want the normal screen
> timeout to kick in when a "display" lock is released. I've seen the
> lack of this many times and it's really annoying. What happens is that
> after you're done watching a 30 minute movie, the application releases
> the lock and the screen immediately shuts off. Attempting to work
> around this by holding the lock for a few minutes past the movie ends
> means that the application has to guess how long timeout the user has
> configured his device to.
> I don't however know of any use cases for having a timeout for
> "system" locks. So I propose they are not supported there.
> I haven't thought about "network" locks enough to know if timeouts
> makes sense there (or if network locks in general are needed).
> / Jonas

Received on Thursday, 14 August 2014 16:55:36 UTC