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?
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?
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.
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- 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?
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.