Intent to Implement: Standby API

[Ilya Bogdanovich]

Contact emails

bogdan...@yandex-team.ru, redc...@yandex-team.ru

 

Spec

http://boiler23.github.io/screen-wake/

The proposal was already discussed in W3C DAP WG, conclusion was - draft looks reasonable, good enough to start work on it.

 

Summary

The API would prevent the device from turning off the screen when idle.

 

Motivation

It may be useful for applications where it’s critical for a user to be able to see the information on screen while performing a different task, e.g. games, cookbooks, video players.

 

Compatibility Risk

Compatibility risks seem to be low. API is small and rather stable.

- No implementation by other browsers (only Firefox OS has very similar non-standard API);

- W3C Editor's Draft;

- No signals from other browser vendors;

- Small API footprint.

 

Ongoing technical constraints

None.

 

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes. However, I’m not sure if Chrome OS has necessary APIs.

 

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=257511

 

Link to entry on the feature dashboard

Not yet. I don't have access rights to add this feature, may some one who does add it for me?

 

Requesting approval to ship?

No.

 

[Darin Fisher]

Hmm, some random questions:

1- What happens if the WakeLock object is garbage collected?

2- This reminds me of pointer lock and fullscreen mode. I wonder if the API should be shaped similarly. (Or, maybe those APIs should evolve to be more like this one.)

3- What happens if you try to acquire the wake lock again when you already have it? Do you have to call release() on both before wake lock is actually released?

Is there a formal spec somewhere?

Thanks,

-Darin

[Sangwhan Moon]

On Tue, Jul 8, 2014 at 7:19 AM, Darin Fisher <da...@chromium.org> wrote:

Hmm, some random questions:

1- What happens if the WakeLock object is garbage collected?

2- This reminds me of pointer lock and fullscreen mode. I wonder if the API should be shaped similarly. (Or, maybe those APIs should evolve to be more like this one.)

3- What happens if you try to acquire the wake lock again when you already have it? Do you have to call release() on both before wake lock is actually released?

Is there a formal spec somewhere?

This is probably the formal version (no idea if it's up to date):
http://w3c.github.io/screen-wake/
 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
Sangwhan Moon [Opera Software ASA]
Software Engineer | Tokyo, Japan

[Darin Fisher]

On Mon, Jul 7, 2014 at 11:16 PM, Sangwhan Moon <sm...@opera.com> wrote:

On Tue, Jul 8, 2014 at 7:19 AM, Darin Fisher <da...@chromium.org> wrote:

Hmm, some random questions:

1- What happens if the WakeLock object is garbage collected?

2- This reminds me of pointer lock and fullscreen mode. I wonder if the API should be shaped similarly. (Or, maybe those APIs should evolve to be more like this one.)

3- What happens if you try to acquire the wake lock again when you already have it? Do you have to call release() on both before wake lock is actually released?

Is there a formal spec somewhere?

This is probably the formal version (no idea if it's up to date):
http://w3c.github.io/screen-wake/
 

Thanks.

It occurs to me that a wake lock should only be something that can be held by a DOMWindow that corresponds to the foreground activity (i.e., current browser tab in the active window on desktop) of the user.

-Darin

[Mounir Lamouri]

On Tue, 8 Jul 2014, at 08:19, Darin Fisher wrote:
> Hmm, some random questions:
>
> 1- What happens if the WakeLock object is garbage collected?
>
> 2- This reminds me of pointer lock and fullscreen mode. I wonder if the
> API
> should be shaped similarly. (Or, maybe those APIs should evolve to be
> more
> like this one.)
>
> 3- What happens if you try to acquire the wake lock again when you
> already
> have it? Do you have to call release() on both before wake lock is
> actually
> released?

Another issue is that there is no way to know if the wake lock was lost
unless polling for whether it is still held. You might imagine that some
UA will allow a page to do a wake lock but still allow the users to
revert the decision (à la fullscreen). Given this can already be
observed by polling |lock.isHeld()|, it sounds reasonable to add an
event notifying about the change.

> Is there a formal spec somewhere?

I don't know if the specification already got a wide support to move
that specific proposal to a WG ED. The GH repository [1] has a couple of
alternative proposals. In addition, it seems that there are some
administrative issues to be solved in order to get this moving to the
DAP WG [2]. Hopefully, we can get the spec moving somewhere, WHATWG
being an open alternative.

This said, even if the specification isn't really stable yet, I think
there is enough support to be optimistic about the outcome and it is a
good idea to start implementing while keeping in mind that the
implementation might change to stay aligned with the specification.

[1] https://github.com/w3c/screen-wake/
[2]
http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0082.html
(and replies in "next in thread")

-- Mounir

[Ilya Bogdanovich]

On 08 июля 2014 г., at 13:53, Mounir Lamouri <mou...@lamouri.fr> wrote:

On Tue, 8 Jul 2014, at 08:19, Darin Fisher wrote:

Hmm, some random questions:

1- What happens if the WakeLock object is garbage collected?

It gets released.

2- This reminds me of pointer lock and fullscreen mode. I wonder if the
API
should be shaped similarly. (Or, maybe those APIs should evolve to be
more
like this one.)

I agree, it would be nice to have similar API for wake locks & fullscreen, as they would be probably used simultaneously.

One possible way here - to add global method like releaseWakeLock(), which would release all wake locks and fire the event on each of them. Another alternative - you can put acquired WakeLock object into global context and get the same behavior as fullscreen mode works.

Choosing between two approaches - pair of global methods (request/release) and acquiring objects that release themselves automatically when GC’d, we chose second, because it seems more safe for us: in 1st approach you have a risk to never turn screen off if you get an exception between calls to request/release. In the 2nd approach, all WakeLock object would be GC’d somehow and released automatically.

3- What happens if you try to acquire the wake lock again when you
already
have it? Do you have to call release() on both before wake lock is
actually
released?

Yes. Alternatively, you can wait while locks get out of scope and GC’d. There may be an issue with undetermined time between going out of scope and firing the GC. This issue may be also solved with adding global method releaseWakeLock(), which would release all active locks.

The idea here was to have separate lock for every scope that needs such capability, without worrying if it was previously acquired or released. This approach seems to be more flexible, than having one global wake lock for all contexts. For example, if you have a game with two windows where the action goes, you should hold the screen awake until both windows are gone. So you just request two wake locks and release them independently when you don’t need them anymore, without worrying how these windows interfere with each other.

Another issue is that there is no way to know if the wake lock was lost
unless polling for whether it is still held. You might imagine that some
UA will allow a page to do a wake lock but still allow the users to
revert the decision (à la fullscreen). Given this can already be
observed by polling |lock.isHeld()|, it sounds reasonable to add an
event notifying about the change.

Agreed, we should add an event for this.

Is there a formal spec somewhere?

I’m actually working on it here:

http://w3c.github.io/screen-wake/

I don't know if the specification already got a wide support to move
that specific proposal to a WG ED. The GH repository [1] has a couple of
alternative proposals. In addition, it seems that there are some
administrative issues to be solved in order to get this moving to the
DAP WG [2]. Hopefully, we can get the spec moving somewhere, WHATWG
being an open alternative.

This said, even if the specification isn't really stable yet, I think
there is enough support to be optimistic about the outcome and it is a
good idea to start implementing while keeping in mind that the
implementation might change to stay aligned with the specification.

We’d be glad to start implementing it now and update our implementation with upcoming spec changes.

[Si Robertson]

I can see browsers needing an alternative/single-shot way to request permission from users to allow/enable all of these APIs (similar to the way Chrome apps and extensions handle things) because most if not all of these APIs (requestFullscreen, requestPointerLock, requestWakeLock, etc) are likely to be used together, and no doubt more APIs will be added in the future. A FPS game is a good example of something that may take advantage of a lot of these APIs.

Would this API also prevent screensavers from starting?

[Si Robertson]

A quick example that just popped into my head ...

  navigator.requestPermissions(['fullscreen','pointerLock','wakeLock']).then(success,error);

Something like that should be considered, IMO.

[mar...@marcosc.com]

On Tuesday, July 8, 2014 5:53:28 AM UTC-4, Mounir Lamouri wrote:

On Tue, 8 Jul 2014, at 08:19, Darin Fisher wrote:
> Hmm, some random questions:
>
> 1- What happens if the WakeLock object is garbage collected?
>
> 2- This reminds me of pointer lock and fullscreen mode. I wonder if the
> API
> should be shaped similarly. (Or, maybe those APIs should evolve to be
> more
> like this one.)
>
> 3- What happens if you try to acquire the wake lock again when you
> already
> have it? Do you have to call release() on both before wake lock is
> actually
> released?

Another issue is that there is no way to know if the wake lock was lost
unless polling for whether it is still held. You might imagine that some
UA will allow a page to do a wake lock but still allow the users to
revert the decision (à la fullscreen). Given this can already be
observed by polling |lock.isHeld()|, it sounds reasonable to add an
event notifying about the change.

> Is there a formal spec somewhere?

I don't know if the specification already got a wide support to move
that specific proposal to a WG ED.

It hasn't, so I marked it as "unofficial". 

 

The GH repository [1] has a couple of
alternative proposals. In addition, it seems that there are some
administrative issues to be solved in order to get this moving to the
DAP WG [2].

 

Hopefully, we can get the spec moving somewhere, WHATWG
being an open alternative.

People at Mozilla would be more in favor of doing this at the WHATWG instead of DAP. When I finish writing up the use cases, I will send them to the WHATWG for discussion. 

 

This said, even if the specification isn't really stable yet, I think
there is enough support to be optimistic about the outcome and it is a
good idea to start implementing while keeping in mind that the
implementation might change to stay aligned with the specification.

We are actually only on the use case gathering phase - which I will publish hopefully later this week. Folks at Mozilla who have seen the proposal are not not really satisfied with it. It fails to cover critical cases like CPU lock: which allows the screen to dim while allowing long running tasks to continue. Folks at Mozilla feel it would be a mistake to simply restrict this to screen wake lock. We have concrete examples of where we use CPU wake lock for long running tasks (e.g., importing contacts). People that have been using our wakelock API (on which this API is based) have also reported difficulty with managing locks (leading to bad situations where locks are not released properly, etc.). 

We need to look at the API more closely to make sure we identity where the issues with the current design are in practice. 

 

[Domenic Denicola]

From: blin...@chromium.org <blin...@chromium.org> on behalf of Ilya Bogdanovich <bogdan...@yandex-team.ru>

>> 1- What happens if the WakeLock object is garbage collected?
>
> It gets released.

I don't think we want to tie the lifecycle of a real-world resource to the garbage-collection algorithm. People will start complaining that their site breaks or behaves unexpectedly when V8 changes their GC algorithm.

> I agree, it would be nice to have similar API for wake locks & fullscreen, as they would be probably used simultaneously.
One possible way here - to add global method like releaseWakeLock(), which would release all wake locks and fire the event on each of them. Another alternative - you can put acquired WakeLock object into global context and get the same behavior as fullscreen mode works.

I am probably missing something---why is it important to have an object representing the lock? For e.g. pointer lock, there is no such object; has that been a problem?

[Elliott Sprehn]

+1, this Lock object is weird, and the GC argument doesn't make sense since it's unlikely you're going to store it on the stack. Any long running process that wants to keep the screen awake is going to happen async, so you're very likely to end up with the lock in a property (or captured by closure), which is then attached to some global model object, which is then kept alive for the duration of the application.

I'd rather we made this the same as requestPointerLock() and requestFullScreen().

- E

[Ilya Bogdanovich]

Ok, I think I haven’t made ​​myself clear.

I don’t agitate to rely on GC. You should release WakeLock objects as soon as possible, after you don’t need them anymore. The only point, why I mentioned GC was that wake lock won’t be kept infinitely if somebody forgot to release it, or failed to release it in case of exception. It seems to be more safe.

Now, why I think it is better to have an object, representing a lock.

Despite the number of common use-cases for fullscreen and wake locks, seems there is a significant difference between them: only one element may be fullscreen at the moment, but there could be many objects needing a wake lock.

For example, let’s consider some web page with video player (sports translation) and some board with score, comments, etc on it. It may be reasonable to keep screen on while at least one of the activities goes on - video translation and some discussion, news, updates on the board, and it is not guaranteed these two activities would start and finish at the same time. It would be easier to deal with wake lock logic of these activities in isolation from each other, so that each has its own lock, and screen would be kept on until there is at least one unreleased lock exist. Having WakeLock objects would be very helpful here. It won't be a stack object, but a property of activity tied to its lifecycle.

Moreover, one of these activities may not be present in some screen configurations (for example, in portrait orientation show both, in landscape show only video). In such cases, reference counted approach would be even more helpful, and having one global wake lock/unlock pair of methods even more complicated.

Also I can imagine an app, showing sensitive notifications that require wake locks, on top of content which requests locks from time to time. If we also consider other types of locks, like cpu locks, mentioned by Marcos, there would be the same situation if we have two long tasks running simultaneously, like importing contacts and importing messages. It seems more handy to work with lock objects in all these cases.

Thanks,

Ilya

[Mounir Lamouri]

On Fri, 11 Jul 2014, at 02:07, Ilya Bogdanovich wrote:
> In such cases, reference counted approach
> would be even more helpful, and having one global wake lock/unlock pair
> of methods even more complicated.

If you have a requestWakeLock()/releaseWakeLock() per browsing context,
it doesn't need to be tight to a native call. In other words, it is not
because a browsing context has called releaseWakeLock() that the UA
should actually release the wake lock. It might need a counter to
release the lock when all the counters are actually released. That way,
if multiple browsing context requested a wake lock, the release will
happen only when all of them are no longer locking.

So, if those the two components you were mentioning are in different
iframes, the UA should be able to handle the situation.

However, if the two components are in the same browsing context, they
can then talk to each other fairly easily and we could imagine that the
page will simply handle that logic by having an internal lock counter
and only call requestWakeLock()/releaseWakeLock() when the lock counter
respectively goes from 0 to 1 and 1 to 0. The exact same thing as Blink
would do with the native platform except that here, the Web API would be
the a native API and the page would provide its layer on top of it.

-- Mounir

[mar...@marcosc.com]

On Tuesday, July 8, 2014 11:53:42 AM UTC-4, mar...@marcosc.com wrote:

Hopefully, we can get the spec moving somewhere, WHATWG
being an open alternative.

People at Mozilla would be more in favor of doing this at the WHATWG instead of DAP. When I finish writing up the use cases, I will send them to the WHATWG for discussion.

I've sent the proposal to the WHATWG:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297231.html

We've also completed the initial use cases gathering phase:
https://w3c-webmob.github.io/wake-lock-use-cases/

Would appreciate any feedback from the Chromium/Blink community.

[Ilya Bogdanovich]

I’ve updated my spec draft based on what we discussed with Mounir and Marcos:

http://boiler23.github.io/screen-wake/

And we already sent initial implementation patches:

https://codereview.chromium.org/399313003

https://codereview.chromium.org/406483004

Thanks,

Ilya

[Elliott Sprehn]

Why is this not requestWakeLock like the other apis? We really need to get better about building consistent apis.

[Chris Wilson]

And can we additionally get this discussed in Web Apps or somewhere else in W3C even if it's not DAP, to get some IP coverage?

[Marcos Caceres]

On July 18, 2014 at 11:13:38 AM, Elliott Sprehn (esp...@google.com) wrote:
> Why is this not requestWakeLock like the other apis? We really need to get
> better about building consistent apis.
>

Putting "WakeLock" in the name of the request method is bad API design. It doesn't allow for extensibility of the API. Having a singleton makes the API much more extensible in that we can put all things related to the API in one place. This is not a case of API purity either - consider the mess we originally had with Screen Orientation API, where the events (and event handler attributes) ended up being on the <body> element (!). We don't want a repeat of that. 



-- 
Marcos Caceres

[Marcos Caceres]

On July 18, 2014 at 12:43:52 PM, Chris Wilson (cwi...@google.com) wrote:
> And can we additionally get this discussed in Web Apps or somewhere else in
> W3C even if it's not DAP, to get some IP coverage?

I had a call with Jeff Jaffe (CEO of W3C) about this yesterday. I've been trying to get this added to the W3C's DAP charter, but it's turning into a bureaucratic nightmare. The charter will only be renewed at the end of the year.

We are currently doing the API at the W3C - but if the W3C doesn't get it's act together quickly we would like to just do it at the WHATWG under a CC0 license and then let the W3C copy/paste it. 

-- 
Marcos Caceres

[Chris Wilson]

That's true enough (though it makes it less attractive for companies to participate) - except the current editors (Ian and Anne, at least) at the WHATWG tend to speak out violently against the copy/paste model.  (I'm pragmatically ambivalent, just pre-voicing their concern.)

This is a good test case for charters and extensions as I try to point out the W3C's agility problems, so thanks for that.  :)