Re: [whatwg] Proposal: Wake Lock API
On 2014/07/15 12:21, Marcos Caceres wrote: ## Use cases ... Note that some devices have a stay-awake-while-held feature that solves the problem for many of the suggested use cases such as reading a book. For others, such as maps while driving, the trend towards connecting devices to the in-car infotainment system and using the in-dash display solves the problem. I think the need for this API will disappear in a relatively short time due to better solutions such as these. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Proposal: Wake Lock API
On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres w...@marcosc.com wrote:
interface WakeLock : EventTarget {
Promisevoid request();
Promisevoid release();
attribute EventHandler onlost;
}
What are the use cases for onlost?
Though I don't really mind exposing this state. My experience is that
if any sane implementation strategy will need to keep some specific
state, and that state affects the behavior of the API, then eventually
someone will come up with a use case for exposing it. And that
exposing it is really easy anyway.
However I think what we'd need is something like
readonly attribute boolean held;
attribute EventHandler onheldchange;
FWIW, the web platform sorely needs a construct for readonly state
variable + event whenever the state changes. I.e. some form of
observable which remembers the last produced value. I had hoped the
Streams would get us closer to that, but the current definition seems
to be too different.
/ Jonas
Re: [whatwg] Proposal: Wake Lock API
On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the web platform sorely needs a construct for readonly state variable + event whenever the state changes. I.e. some form of observable which remembers the last produced value. I had hoped the Streams would get us closer to that, but the current definition seems to be too different. Isn't that Object.observe() with custom records produced by the specific object you are defining for the property you want to enable this for (in this case held, it seems like)? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Wake Lock API
On Wed, Aug 20, 2014 at 1:33 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the web platform sorely needs a construct for readonly state variable + event whenever the state changes. I.e. some form of observable which remembers the last produced value. I had hoped the Streams would get us closer to that, but the current definition seems to be too different. Isn't that Object.observe() with custom records produced by the specific object you are defining for the property you want to enable this for (in this case held, it seems like)? That's a good question. It'd be awesome if Object.observe() solved this problem for us. One thing that I'd worry about is that it'll be hard for authors to know which properties are observable, and which ones aren't. But maybe that's something we can live with. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On 08/20/2014 11:33 AM, Anne van Kesteren wrote: On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the web platform sorely needs a construct for readonly state variable + event whenever the state changes. I.e. some form of observable which remembers the last produced value. I had hoped the Streams would get us closer to that, but the current definition seems to be too different. Isn't that Object.observe() with custom records produced by the specific object you are defining for the property you want to enable this for (in this case held, it seems like)? Object.observe() + some custom records sounds rather inconsistent API. Why would one getter in some prototype be handle differently to other getters? (and it is not too clear how one would implement that.)
Re: [whatwg] Proposal: Wake Lock API
On Wednesday, August 20, 2014 at 5:15 AM, Olli Pettay wrote: On 08/20/2014 11:33 AM, Anne van Kesteren wrote: On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc (mailto:jo...@sicking.cc) wrote: FWIW, the web platform sorely needs a construct for readonly state variable + event whenever the state changes. I.e. some form of observable which remembers the last produced value. I had hoped the Streams would get us closer to that, but the current definition seems to be too different. Isn't that Object.observe() with custom records produced by the specific object you are defining for the property you want to enable this for (in this case held, it seems like)? Object.observe() + some custom records sounds rather inconsistent API. Why would one getter in some prototype be handle differently to other getters? (and it is not too clear how one would implement that.) Agree - a custom thing would not be great. And of course Object.observe would work really nicely, but I've been told a bunch of times by various people that we can't use Object.observe on DOM APIs (this *really* sucks). Getting a bit off topic, but it would be nice if we had a DOM Observer (kinda like a mutation observer) that returned you the same record as Object.observe and could be used with the attributes of WebIDL defined objects. It would make designing, and using, these APIs much simpler.
Re: [whatwg] Proposal: Wake Lock API
On Wed, Aug 20, 2014 at 5:09 PM, Marcos Caceres w...@marcosc.com wrote: And of course Object.observe would work really nicely, but I've been told a bunch of times by various people that we can't use Object.observe on DOM APIs (this *really* sucks). Not by default, but we can make it work as I said. We wouldn't do it for innerHTML, but we might for input.value or some such. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Wake Lock API
On Wednesday, August 20, 2014 at 11:14 AM, Anne van Kesteren wrote:
On Wed, Aug 20, 2014 at 5:09 PM, Marcos Caceres w...@marcosc.com
(mailto:w...@marcosc.com) wrote:
And of course Object.observe would work really nicely, but I've been told a
bunch of times by various people that we can't use Object.observe on DOM
APIs (this *really* sucks).
Not by default, but we can make it work as I said. We wouldn't do it
for innerHTML, but we might for input.value or some such.
Ok, if we get [Observable] in WebIDL, then the API basically becomes something
neat like:
```
partial interface Document {
[Observable] attribute boolean keepScreenOn;
}
```
So nice.
Re: [whatwg] Proposal: Wake Lock API
On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote: Note that in the API that I'm proposing, there is no way to accidentally rely on GC behavior. If a WakeLock object is GCed before it has been release()ed, then the lock is held indefinitely (until the user leaves the page of course). I.e. an unbalanced request() and release() in both the currently proposed API, and in the API that I propose behave the same, the lock is held indefinitely. Any objects getting GCed does not change this. I overlooked that aspect, my apologies. It sounds good. I am not sure if that would be safer than global methods in the sense that developers will still be able to shoot themselves in the foot by not calling .release() or might assume that .release() will be called upon object destruction. How would you handle feature detection with this design? -- Mounir
Re: [whatwg] Proposal: Wake Lock API
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote: Note that in the API that I'm proposing, there is no way to accidentally rely on GC behavior. If a WakeLock object is GCed before it has been release()ed, then the lock is held indefinitely (until the user leaves the page of course). I.e. an unbalanced request() and release() in both the currently proposed API, and in the API that I propose behave the same, the lock is held indefinitely. Any objects getting GCed does not change this. I overlooked that aspect, my apologies. It sounds good. I am not sure if that would be safer than global methods in the sense that developers will still be able to shoot themselves in the foot by not calling .release() or might assume that .release() will be called upon object destruction. How would you handle feature detection with this design? Assuming there are multiple types of wakelock classes, you just test for their existence. ~TJ
Re: [whatwg] Proposal: Wake Lock API
Tab Atkins Jr. jackalm...@gmail.com writes:
On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
[…]
Seems to me a declarative solution (like CSS) might be appropriate.
@media screen {
video:playing {
wake-lock: display 15s;
}
}
article.recipe:target {
wake-lock: display;
}
That's not a terrible idea.
Thanks. ;)
The CSSWG is generally hesitant to put behavior-altering things in
CSS, but some bleed-through is fine, and this can be argued as an
aspect of appearance.
I think compared to the “will-change“ property, a “wake-lock” property
would fare well. I do wonder, however, how the concept would translate
to different display technologies – like e-ink, which does not need a
wake lock, or physical media, which decompose after some time.
This solves the GC and locking issues (the latter by delegating state
management to CSS, which everyone already knows to use).
It would also make it easily possible to express logic similar to “do
not power off the screen immediately after a video is playing” in UA or
even user stylesheets in a no-nonsense and clearly interoperable way.
A CSS solution could also limit abuse if it included a “max-wake-lock”
property.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Wake Lock API
On August 19, 2014 at 11:16:19 AM, Nils Dagsson Moskopp (n...@dieweltistgarnichtso.net) wrote: Tab Atkins Jr. writes: This solves the GC and locking issues (the latter by delegating state management to CSS, which everyone already knows to use). It would also make it easily possible to express logic similar to “do not power off the screen immediately after a video is playing” in UA or even user stylesheets in a no-nonsense and clearly interoperable way. A CSS solution could also limit abuse if it included a “max-wake-lock” property. Can you describe what you mean here in a bit more detail?
Re: [whatwg] Proposal: Wake Lock API
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote: Note that in the API that I'm proposing, there is no way to accidentally rely on GC behavior. If a WakeLock object is GCed before it has been release()ed, then the lock is held indefinitely (until the user leaves the page of course). I.e. an unbalanced request() and release() in both the currently proposed API, and in the API that I propose behave the same, the lock is held indefinitely. Any objects getting GCed does not change this. I overlooked that aspect, my apologies. It sounds good. I am not sure if that would be safer than global methods in the sense that developers will still be able to shoot themselves in the foot by not calling .release() or might assume that .release() will be called upon object destruction. Indeed. I can't think of a way to fix that without also breaking some use cases. I.e. we could forcefully release all locks after a timeout, but that'll definitely break some use cases such as long videos, or heavy background processing. How would you handle feature detection with this design? This is a good question. I don't have a better solution than adding separate DisplayWakeLock() and SystemWakeLock() classes. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On Tue, Aug 19, 2014 at 11:07 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr wrote: How would you handle feature detection with this design? This is a good question. I don't have a better solution than adding separate DisplayWakeLock() and SystemWakeLock() classes. Which, as others have noted, are what we want to do anyway, beyond the feature-testing angle. Different WakeLocks can grow different methods down the line. ~TJ
Re: [whatwg] Proposal: Wake Lock API
On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate DisplayWakeLock() and SystemWakeLock() classes.
Might make sense to do it this way regardless. It might be that we need to add
different behavior for each type of lock in the future.
Ok, so taking into consideration the feedback received so far - how about
something like:
```
[Constructor]
interface DisplayLock : WakeLock {
static readonly attribute boolean isHeld;
}
[Constructor]
interface SystemLock : WakeLock {
static readonly attribute boolean isHeld;
}
interface WakeLock : EventTarget {
Promisevoid request();
Promisevoid release();
attribute EventHandler onlost;
}
```
Usage:
```
//feature detect + lock check
if (DisplayLock !DisplayLock.isHeld){
var lock = new DisplayLock();
lock.request().then(yay,boo);
//listen in case the lock is lost:
lock.addEventListener(lost, function(){
//try again maybe when the battery has more juice
});
}
```
Re: [whatwg] Proposal: Wake Lock API
On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres w...@marcosc.com wrote:
On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote:
How would you handle feature detection with this design?
This is a good question. I don't have a better solution than adding
separate DisplayWakeLock() and SystemWakeLock() classes.
Might make sense to do it this way regardless. It might be that we need to
add different behavior for each type of lock in the future.
Ok, so taking into consideration the feedback received so far - how about
something like:
```
[Constructor]
interface DisplayLock : WakeLock {
static readonly attribute boolean isHeld;
}
[Constructor]
interface SystemLock : WakeLock {
static readonly attribute boolean isHeld;
}
Why is isHeld still used here? You don't need it to avoid squashing
someone else's lock with this design, and several people have pointed
out that exposing it is a footgun, as people might check it and decide
they don't need to request their own lock (only to be screwed when the
other lock releases earlier or later than they expected).
~TJ
Re: [whatwg] Proposal: Wake Lock API
On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Why is isHeld still used here? You don't need it to avoid squashing someone else's lock with this design, and several people have pointed out that exposing it is a footgun, as people might check it and decide they don't need to request their own lock (only to be screwed when the other lock releases earlier or later than they expected). It's the only authoritative source of truth. But ok, fair point about the footgun. Consider the static dropped. -- Marcos Caceres
Re: [whatwg] Proposal: Wake Lock API
On Tue, Aug 19, 2014 at 1:44 PM, Marcos Caceres w...@marcosc.com wrote: On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: Why is isHeld still used here? You don't need it to avoid squashing someone else's lock with this design, and several people have pointed out that exposing it is a footgun, as people might check it and decide they don't need to request their own lock (only to be screwed when the other lock releases earlier or later than they expected). It's the only authoritative source of truth. But ok, fair point about the footgun. Consider the static dropped. I mean, you could put a non-static isHeld on any individual lock, if you want to know whether this particular lock is held or released. I just don't think there's any reason to pass information around about the global lock state, if you're not being required to use that information for coordination purposes. ~TJ
Re: [whatwg] Proposal: Wake Lock API
On Sat, 16 Aug 2014, at 08:40, Jonas Sicking wrote: On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote: 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. It seems that we already discussed using an object and this solution was dismissed because of this model being error-prone. Where was this discussed? Why was it considered more error prone? Was it related to the patterns discussed at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html There might have been some discussions in the DAP WG (but the archives website isn't helping). There was definitely at thread in blink-dev [1] and you might want to have a look at the GitHub repo [2]. By the way, it seems that this API might be worked in the DAP WG [3]. It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. The problem arises when you have several semi-independent pieces of code within a single page. Given that request() and release() is likely going to happen in response to very different UI events or IO events, it makes it fairly easy to accidentally have unbalanced calls. Consider for example a lock which is released either when a video reaches its end, when the user presses the pause button, or when the user close the dialog in which the video is rendered. It seems quite easy to end up with a race where if the user close the dialog right when the video ends, that release() would get called twice. Or if the user pause the video first and then close the dialog that release() would get called twice. If there's only one subsystem of the page that uses a display lock, then this is not a big deal. The extra call to release() would cause an rejection, but hopefully that won't break the page. It is possible that the API might behave differently and the first release() will release the lock even if lock() was called multiple times. I guess the scope of the lock could be the browsing context so a website will not end up conflicting with iframes. However, if a websites embeds libraries that use this API, it will need to coordinate. However if there are multiple subsystems that all use a display lock, it would mean that those subsystems might stomp on each other's attempts at holding a display lock. The effect would be that the display lock is released too early. I don't care strongly about this though. It's pretty easy for pages to write a wrapper around the currently proposed API to implement the API that I'm proposing. I understand the problem and I agree that an object-based approach would be nicer in theory because the scope of the lock would be well defined. However, it's a very uncommon pattern as far as Web APIs are concerned and I would worry that developers would end up doing things wrong and depend on the GC behaviour without even being aware of it. [1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/SzVuAi2KRhA/OaNDiHOKl8gJ [2] https://github.com/w3c/wake-lock [3] http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0035.html -- Mounir
Re: [whatwg] Proposal: Wake Lock API
On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Jonas Sicking jo...@sicking.cc writes:
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
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.
It seems that we already discussed using an object and this solution was
dismissed because of this model being error-prone.
Where was this discussed? Why was it considered more error prone? Was
it related to the patterns discussed at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html
It's also not clear
how this solution is superior than the current solution [1] with regards
to multiple releases or requests. In [1], if you call .request() or
.release() multiple time, the promise reacts appropriately.
The problem arises when you have several semi-independent pieces of
code within a single page. Given that request() and release() is
likely going to happen in response to very different UI events or IO
events, it makes it fairly easy to accidentally have unbalanced calls.
Consider for example a lock which is released either when a video
reaches its end, when the user presses the pause button, or when the
user close the dialog in which the video is rendered. It seems quite
easy to end up with a race where if the user close the dialog right
when the video ends, that release() would get called twice. Or if the
user pause the video first and then close the dialog that release()
would get called twice.
Seems to me a declarative solution (like CSS) might be appropriate.
@media screen {
video:playing {
wake-lock: display 15s;
}
}
article.recipe:target {
wake-lock: display;
}
That's not a terrible idea. The CSSWG is generally hesitant to put
behavior-altering things in CSS, but some bleed-through is fine, and
this can be argued as an aspect of appearance.
This solves the GC and locking issues (the latter by delegating state
management to CSS, which everyone already knows to use).
~TJ
Re: [whatwg] Proposal: Wake Lock API
On Mon, Aug 18, 2014 at 2:04 AM, Mounir Lamouri mou...@lamouri.fr wrote: It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. The problem arises when you have several semi-independent pieces of code within a single page. Given that request() and release() is likely going to happen in response to very different UI events or IO events, it makes it fairly easy to accidentally have unbalanced calls. Consider for example a lock which is released either when a video reaches its end, when the user presses the pause button, or when the user close the dialog in which the video is rendered. It seems quite easy to end up with a race where if the user close the dialog right when the video ends, that release() would get called twice. Or if the user pause the video first and then close the dialog that release() would get called twice. If there's only one subsystem of the page that uses a display lock, then this is not a big deal. The extra call to release() would cause an rejection, but hopefully that won't break the page. It is possible that the API might behave differently and the first release() will release the lock even if lock() was called multiple times. I guess the scope of the lock could be the browsing context so a website will not end up conflicting with iframes. However, if a websites embeds libraries that use this API, it will need to coordinate. I'd rather have request() and release() work as they are defined now. Otherwise coordinating becomes even harder as the specification does not provide a coordination mechanism. However if there are multiple subsystems that all use a display lock, it would mean that those subsystems might stomp on each other's attempts at holding a display lock. The effect would be that the display lock is released too early. I don't care strongly about this though. It's pretty easy for pages to write a wrapper around the currently proposed API to implement the API that I'm proposing. I understand the problem and I agree that an object-based approach would be nicer in theory because the scope of the lock would be well defined. However, it's a very uncommon pattern as far as Web APIs are concerned and I would worry that developers would end up doing things wrong and depend on the GC behaviour without even being aware of it. Note that in the API that I'm proposing, there is no way to accidentally rely on GC behavior. If a WakeLock object is GCed before it has been release()ed, then the lock is held indefinitely (until the user leaves the page of course). I.e. an unbalanced request() and release() in both the currently proposed API, and in the API that I propose behave the same, the lock is held indefinitely. Any objects getting GCed does not change this. Again, I don't feel terribly strongly about this as it's easy to shim in either direction. / Jonas
Re: [whatwg] Proposal: Wake Lock API
I think it'd be unfortunate if this API had just one shared lock per browsing context and required components on the page to coordinate locking, but provided no means to do so. This will force authors of libraries and components to create dummy iframes just to have their private lock, and libraries/pages without such workaround will be messing up each other's locks. Having just a single shared DOM0-style event handler navigator.wakeLock.onlost looks especially jarring. I would expect this to be a proper DOM event that can be used with normal addEventListener (please avoid repeating the mistake of matchMedia). To make some coordination possible, the simplest method could be to keep track of number of lock requests and releases, like retain/release in Objective-C: navigator.wakeLock.request(screen); // locks navigator.wakeLock.request(screen); // increases lock count navigator.wakeLock.release(screen); // not released yet, but decreases lock count navigator.wakeLock.release(screen); // now released for real However, as you probably know from Objective-C, perfect balancing of retain/release takes care and discipline. Personally, I wouldn't trust all 3rd party libraries/widgets/ads to be careful with this. In fact, I expect some clever libraries to ruin this with: while(navigator.wakeLock.isHeld(screen)) navigator.wakeLock.release(screen); // just release the damn thing in my leaky code! Therefore, if WakeLock needs to be purely JS API, I strongly prefer having WakeLock available only as an object instance, but without exposing GC behavior—if it's lost, it's like a missing release call. If devtools ever get monitoring of unhanded errors in Promise objects, they could also warn against lost WakeLock objects—it's the same type of problem dependent on GC. I'm assuming that release would work only once on each lock object: var lock = new WakeLock(screen); lock.release(); lock.release(); // ignored, so it doesn't unlock any other component's lock This makes coordination easier: each page component can easily create their own lock independently (without needing to create an iframe to get their own lock), and can't release any other component's lock. -- regards, Kornel
Re: [whatwg] Proposal: Wake Lock API
On Monday, August 18, 2014 at 6:24 PM, Kornel Lesiński wrote: I think it'd be unfortunate if this API had just one shared lock per browsing context and required components on the page to coordinate locking, but provided no means to do so. The API allows scripts to check which locks are currently held (as either a `isHeld()` or `getCurrentLocks()`, for which I just sent a PR for). This will force authors of libraries and components to create dummy iframes just to have their private lock, and libraries/pages without such workaround will be messing up each other's locks. Currently, iframes are not allowed to have locks - only top-level browsing contexts are. This is to avoid things like embedded ads from requesting wake locks. Having just a single shared DOM0-style event handler navigator.wakeLock.onlost looks especially jarring. I would expect this to be a proper DOM event that can be used with normal addEventListener (please avoid repeating the mistake of matchMedia). Oops! I forgot to put that `WakeLock` inherits from `EventTarget`. It's always been the intention that you will have .addEventListener! I've sent a PR to fix this. To make some coordination possible, the simplest method could be to keep track of number of lock requests and releases, like retain/release in Objective-C: navigator.wakeLock.request(screen); // locks navigator.wakeLock.request(screen); // increases lock count navigator.wakeLock.release(screen); // not released yet, but decreases lock count navigator.wakeLock.release(screen); // now released for real In my dummy implementation, I've just been using (the Swift equivalent of): [UIApplication sharedApplication].idleTimerDisabled = YES; On MacOS, I thought the right thing to do (tm) according to Apple was [1] (see listing 2)? I'm pretty sure that's what we do already in Gecko for videos as we've been investigating repurposing the video code for wake locks. So, I've not seen the request/release behavior you describe above (at least not in the context of wake locks on MacOS/iOS). I guess it's used as an idiom maybe in other places? However, as you probably know from Objective-C, Full disclosure, I barely know objective-c ;) perfect balancing of retain/release takes care and discipline. Personally, I wouldn't trust all 3rd party libraries/widgets/ads to be careful with this. In fact, I expect some clever libraries to ruin this with: while(navigator.wakeLock.isHeld(screen)) navigator.wakeLock.release(screen); // just release the damn thing in my leaky code! That would just halt the browser as the script would never complete: currently releasing happens async once the system acknowledges that the release has been granted. I'm not sure if there is a use case for that behavior - it's just what is currently/sorta roughly proposed in the spec. Therefore, if WakeLock needs to be purely JS API, I strongly prefer having WakeLock available only as an object instance, but without exposing GC behavior—if it's lost, it's like a missing release call. If devtools ever get monitoring of unhanded errors in Promise objects, they could also warn against lost WakeLock objects—it's the same type of problem dependent on GC. I'm assuming that release would work only once on each lock object: var lock = new WakeLock(screen); lock.release(); lock.release(); // ignored, so it doesn't unlock any other component's lock This makes coordination easier: each page component can easily create their own lock independently (without needing to create an iframe to get their own lock), and can't release any other component's lock. Personally, I don't know if I agree that it makes coordination easier. Seems that having a centralized place to check what is currently being held makes life a lot easier, because it allows scripts to check if they actually need to request a lock or not. If you have some objects requesting and others releasing, then it makes a huge mess because you need to track down which object screwed up the lock. And if GC also then works to release the locks, then there is no certainty as to what is actually releasing the lock or when. [1] https://developer.apple.com/library/mac/qa/qa1340/_index.html
Re: [whatwg] Proposal: Wake Lock API
On Mon, Aug 18, 2014 at 4:37 PM, Marcos Caceres w...@marcosc.com wrote: while(navigator.wakeLock.isHeld(screen)) navigator.wakeLock.release(screen); // just release the damn thing in my leaky code! That would just halt the browser as the script would never complete: currently releasing happens async once the system acknowledges that the release has been granted. I'm not sure if there is a use case for that behavior - it's just what is currently/sorta roughly proposed in the spec. I don't think the sync part was the important aspect here. You could easily rewrite that as an async loop. The point is that it's easy for developers to end up trying to work around bugs in their own code by simply doing extra releases. Or end up with bugs where they accidentally release too many times and so stomp on other components. Therefore, if WakeLock needs to be purely JS API, I strongly prefer having WakeLock available only as an object instance, but without exposing GC behavior--if it's lost, it's like a missing release call. If devtools ever get monitoring of unhanded errors in Promise objects, they could also warn against lost WakeLock objects--it's the same type of problem dependent on GC. I'm assuming that release would work only once on each lock object: var lock = new WakeLock(screen); lock.release(); lock.release(); // ignored, so it doesn't unlock any other component's lock This makes coordination easier: each page component can easily create their own lock independently (without needing to create an iframe to get their own lock), and can't release any other component's lock. Personally, I don't know if I agree that it makes coordination easier. Seems that having a centralized place to check what is currently being held makes life a lot easier, because it allows scripts to check if they actually need to request a lock or not. Why does the ability to check if a lock is held make coordination easier? Checking if they need to request a lock or if someone else is already doing it seems like a very bad code pattern which actually makes coordination harder. It makes it very easy to get confused and try to rely on party X to hold a lock, but then it turns out that in reality it was Y holding the lock, but Y releases the lock much sooner and now end up holding a lock for a shorter time than intended. Am I missing something? If you have some objects requesting and others releasing, then it makes a huge mess because you need to track down which object screwed up the lock. This is not what the proposal is. The proposal is that if a WakeLock instance x is used to grab a lock, then the lock will be held until x.release() is called. Any calls on other WakeLock instances will not cause the lock to be released. Only one all WakeLock instances that have had request() called on them also gets a call to release(), does the lock get released. Losing track of the instance that you called request() on, then that is equivalent to losing track of how many time you have called wakeLock.request(x). There is no way to get correctly out of that situation. And if GC also then works to release the locks, then there is no certainty as to what is actually releasing the lock or when. Can we please stop talking about GC. I don't think anyone has made a serious proposal where GC releases a lock, or where GC is otherwise exposed. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On Monday, August 18, 2014 at 6:24 PM, Kornel Lesiński wrote:
I think it'd be unfortunate if this API had just one shared lock per
browsing context and required components on the page to coordinate locking,
but provided no means to do so.
The API allows scripts to check which locks are currently held (as either a
`isHeld()` or `getCurrentLocks()`, for which I just sent a PR for).
I don't understand how is that helping.
Let's say I have embedded a Slideshare presentation and a YouTube video on my
page. I start watching slides, then start playing the video, then finish
watching slides.
When Slideshare finishes and wants to release the lock, it can't learn via this
API whether YouTube still wants the lock. When Slideshare started isHeld was
false, but setting it back to that original state would be incorrect. When
Slideshare finished isHeld was true, but that doesn't tell anything either,
since Slideshare itself set it to true.
The only way I see for coordinating lock between independent components on the
page is not via isHeld(), but by defensively re-setting the lock.
In my previous example both Slideshare and YouTube would have to watch for
'lost' events (but not via the Netscape-style onlost footgun!) and keep
re-requesting the lock soon after it's been released, for as long as they need
it.
IMHO that's really ugly.
If re-requesting is supposed to be the pattern for maintaining locks properly,
then the whole API could be cut down to just events:
window.addEventListener('beforeScreenLock', function(e) {
if (stillShowingStuff) e.preventDefault();
}, false);
The browser would fire beforeScreenLock event every time the OS is about to
turn the screen off. To keep the screen on for another while the page just
needs to prevent the event.
This will force authors of libraries and components to create dummy iframes
just to have their private lock, and libraries/pages without such workaround
will be messing up each other's locks.
Currently, iframes are not allowed to have locks - only top-level browsing
contexts are. This is to avoid things like embedded ads from requesting wake
locks.
That's a noble goal. However, it may not be effective against ads in practice,
because majority of ads are embedded using script. OTOH it may prevent use of
locks in well-behaved embedded documents (slideshows and the like).
At very least I suggest controlling this like other potentially-annoying
features via iframe sandbox=allow-locks.
To make some coordination possible, the simplest method could be to keep
track of number of lock requests and releases, like retain/release in
Objective-C:
navigator.wakeLock.request(screen); // locks
navigator.wakeLock.request(screen); // increases lock count
navigator.wakeLock.release(screen); // not released yet, but decreases
lock count
navigator.wakeLock.release(screen); // now released for real
In my dummy implementation, I've just been using (the Swift equivalent of):
[UIApplication sharedApplication].idleTimerDisabled = YES;
I admire elegance of most of Cocoa's APIs, but I don't think design of that one
is worth copying. It's global shared mutable state, and there's even negation
in the property name—it may have been a quick hack that slipped though Cocoa QA
(the documentation even includes a warning that it should be used with care and
only when necessary).
Apple has tight control over what apps do, and iOS apps generally don't have as
many code mashups as web pages, so such primitive fragile API may be less of a
concern for Apple.
Other APIs you've liked to
(https://developer.apple.com/library/mac/qa/qa1340/_index.html) are better:
IOPMAssertionCreateWithName/IOPMAssertionRelease creates instances that can be
individually independently released, so each component can have its own lock
and they can't release each other's locks accidentally (similar to the `new
WakeLock()` proposal).
IORegisterForSystemPower uses a callback (similar to the
`event.preventDefault()` solution I've outlined earlier in this mail).
This makes coordination easier: each page component can easily create their
own lock independently (without needing to create an iframe to get their own
lock), and can't release any other component's lock.
Personally, I don't know if I agree that it makes coordination easier. Seems
that having a centralized place to check what is currently being held makes
life a lot easier, because it allows scripts to check if they actually need
to request a lock or not.
No! That's a footgun! You can't do `if (!isHeld()) request()`, because the
other component holding the lock may have shorter lifetime than yours, and you
can't know that.
--
regards, Kornel
Re: [whatwg] Proposal: Wake Lock API
Jonas Sicking jo...@sicking.cc writes:
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
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.
It seems that we already discussed using an object and this solution was
dismissed because of this model being error-prone.
Where was this discussed? Why was it considered more error prone? Was
it related to the patterns discussed at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html
It's also not clear
how this solution is superior than the current solution [1] with regards
to multiple releases or requests. In [1], if you call .request() or
.release() multiple time, the promise reacts appropriately.
The problem arises when you have several semi-independent pieces of
code within a single page. Given that request() and release() is
likely going to happen in response to very different UI events or IO
events, it makes it fairly easy to accidentally have unbalanced calls.
Consider for example a lock which is released either when a video
reaches its end, when the user presses the pause button, or when the
user close the dialog in which the video is rendered. It seems quite
easy to end up with a race where if the user close the dialog right
when the video ends, that release() would get called twice. Or if the
user pause the video first and then close the dialog that release()
would get called twice.
Seems to me a declarative solution (like CSS) might be appropriate.
@media screen {
video:playing {
wake-lock: display 15s;
}
}
article.recipe:target {
wake-lock: display;
}
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: Wake Lock API
Den 14-08-2014 kl. 23:02 skrev Jonas Sicking:
On Thu, Aug 14, 2014 at 9:55 AM, Jesper Kristensen
m...@jesperkristensen.dk wrote:
Hi
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.
The main use case for system locks in my mind is for applications that
need to do some short but important processing. For example a camera
app wanting to do some HDR processing of an image before saving it to
disk. It seems like it would be very annoying if a notification was
shown any time the user took a picture.
I still think it's a very interesting idea though.
Both Android and iOS have notifications showing whenever any app does
background sync (although you cannot easily see which app it is, which I
think is an issue). So I think it can be implemented in a way that is
not too annoying. In addition you could choose to only show the
notification when the page holding the lock is in the background.
/Jesper Kristensen
Re: [whatwg] Proposal: Wake Lock API
On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote: 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. It seems that we already discussed using an object and this solution was dismissed because of this model being error-prone. It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. Typically, if you try to release() an un-hold lock, it will reject the promise. Is that something you are not satisfied with? [1] http://w3c.github.io/wake-lock/ ? -- Mounir
Re: [whatwg] Proposal: Wake Lock API
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote: 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. It seems that we already discussed using an object and this solution was dismissed because of this model being error-prone. Where was this discussed? Why was it considered more error prone? Was it related to the patterns discussed at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html It's also not clear how this solution is superior than the current solution [1] with regards to multiple releases or requests. In [1], if you call .request() or .release() multiple time, the promise reacts appropriately. The problem arises when you have several semi-independent pieces of code within a single page. Given that request() and release() is likely going to happen in response to very different UI events or IO events, it makes it fairly easy to accidentally have unbalanced calls. Consider for example a lock which is released either when a video reaches its end, when the user presses the pause button, or when the user close the dialog in which the video is rendered. It seems quite easy to end up with a race where if the user close the dialog right when the video ends, that release() would get called twice. Or if the user pause the video first and then close the dialog that release() would get called twice. If there's only one subsystem of the page that uses a display lock, then this is not a big deal. The extra call to release() would cause an rejection, but hopefully that won't break the page. However if there are multiple subsystems that all use a display lock, it would mean that those subsystems might stomp on each other's attempts at holding a display lock. The effect would be that the display lock is released too early. I don't care strongly about this though. It's pretty easy for pages to write a wrapper around the currently proposed API to implement the API that I'm proposing. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On Wed, Aug 13, 2014 at 9:46 PM, Biju bijumaill...@gmail.com wrote: On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote: 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. If application made a x.request() then x got garbage collected system should automatically do x.release(); No. We don't want authors to come to rely on GC to have their locks released. That would cause very erratic behavior where sometimes the lock would be held for 2 seconds after the last reference to 'x' was removed, and sometimes the lock would be held for 30 minutes past that point. In other words, it would make GC observable. Not always observable by the page, but by the user which can be just as bad. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On 14 August 2014 03:07, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 13, 2014 at 9:46 PM, Biju bijumaill...@gmail.com wrote:
On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote:
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.
If application made a x.request() then x got garbage collected
system should automatically do x.release();
No. We don't want authors to come to rely on GC to have their locks
released. That would cause very erratic behavior where sometimes the
lock would be held for 2 seconds after the last reference to 'x' was
removed, and sometimes the lock would be held for 30 minutes past that
point.
In other words, it would make GC observable. Not always observable by
the page, but by the user which can be just as bad.
/ Jonas
So what happens when we have following function call.
How do we release the runaway lock request.
Another case is a page made lock and user navigate away from the page.
Do the browser keep the lock for ever ?
function xyz(){
do_something_1();
x = new WakeLock(display);
x.request();
do_something_2();
throw some runtime error occurred;
do_something_3();
x.release();
do_something_4();
}
Re: [whatwg] Proposal: Wake Lock API
Jonas Sicking jo...@sicking.cc writes: On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com 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: http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books 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. So what would happen if I want my laptop to go to into low-power mode by closing the lid? Would I have to close a lot of risky web pages first? 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. Such a CPU lock function looks to me like they can be easily abused, without users necessarily finding out why their battery is drained or their handset is becoming warm – while having no recourse except for not using the offending web page (but note that web pages deemed important by users can get away with all kinds of abusive stuff, like displaying advertising and therefore using up bandwith and battery). 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. I believe this is something that can be entirely done by the device already, for example using motion or proximity detection built in. 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
Re: [whatwg] Proposal: Wake Lock API
Hi
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 w...@marcosc.com 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:
http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books
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
Re: [whatwg] Proposal: Wake Lock API
On Thu, Aug 14, 2014 at 4:44 AM, Biju bijumaill...@gmail.com wrote:
So what happens when we have following function call.
How do we release the runaway lock request.
Another case is a page made lock and user navigate away from the page.
Do the browser keep the lock for ever ?
function xyz(){
do_something_1();
x = new WakeLock(display);
x.request();
do_something_2();
throw some runtime error occurred;
do_something_3();
x.release();
do_something_4();
}
Same thing as
function xyz(){
do_something_1();
navigator.wakeLock.request(display)
do_something_2();
throw some runtime error occurred;
do_something_3();
navigator.wakeLock.release(display)
do_something_4();
}
I.e. the lock is held forever.
/ Jonas
Re: [whatwg] Proposal: Wake Lock API
On Thu, Aug 14, 2014 at 6:33 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: So what would happen if I want my laptop to go to into low-power mode by closing the lid? Would I have to close a lot of risky web pages first? We need indeed something to prevent abuse here. Especially for CPU locks given that they are largely invisible (and unactionable) to the user. This is of course independent of what API syntax we use. One solution that I think we'd use in FirefoxOS is to bring up a dialog when the system lock is used. Unless the user has installed the page by using bookmark to homepage or something similar. And for things that have been bookmarked to homepage we'd track their battry usage and inform the user how much battery each bookmarked website uses. / Jonas
Re: [whatwg] Proposal: Wake Lock API
On Thu, Aug 14, 2014 at 9:55 AM, Jesper Kristensen
m...@jesperkristensen.dk wrote:
Hi
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.
The main use case for system locks in my mind is for applications that
need to do some short but important processing. For example a camera
app wanting to do some HDR processing of an image before saving it to
disk. It seems like it would be very annoying if a notification was
shown any time the user took a picture.
I still think it's a very interesting idea though.
/ Jonas
Jesper Kristensen
Den 14-08-2014 kl. 03:00 skrev Jonas Sicking:
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com 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:
http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books
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
Re: [whatwg] Proposal: Wake Lock API
Additionally in the browser UI, if user can get a way to find which tabs/pages are locking the system/display it will be great help.
Re: [whatwg] Proposal: Wake Lock API
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com 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: http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books 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
Re: [whatwg] Proposal: Wake Lock API
On 15 July 2014 15:51, Marcos Caceres w...@marcosc.com wrote: On July 15, 2014 at 3:31:32 PM, Jasper St. Pierre (jstpie...@mecheye.net) wrote: Should the lock automatically be released if the user switches to a different tab or somehow makes the content unviewable? Yes. But it could be automatically reapplied once the user switches back to the tab/window. This could happen transparently. This should be applicable to screen lock only. For system lock an app should be able go to background tab and ask for for lock, UC web radio app, or a navigation system giving voice turn by turn instruction. On 17 July 2014 10:17, Marcos Caceres w...@marcosc.com wrote: display = keep display on + system/cpu + network network (wifi/cell) = system/cpu + network (screen off) system = just cpu, turn off screen and radio. If somebody is reading a long page, why do we need to keep network on? so if it is only display lock, network can be disconnected and only need to automatically reconnect when there is another network request. On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote: 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. If application made a x.request() then x got garbage collected system should automatically do x.release(); 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 wish you tube app on android implemented this. As user it is annoying to me when screen turns off immediately after a long video. I have set time out for divide to 5 minutes, but if you tube app can hold the screen for a minute, I will be happy. Or in other words we don't have to wait another system timeout duration, it can be just 1 or 2 extra minute after lock release on the screen.
Re: [whatwg] Proposal: Wake Lock API
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy to do with the tools the
platform already provides. The argument to support this feature in the
github issue was that it will prevent developers to forget releasing the
lock but I have a hard time believing that developers forgetting to
release a lock would use a timeout that is probably more painful and
error-prone.
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.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
You might want something like:
partial interface WakeLock {
readonly attribute WakeLockType[] currentLocks;
};
Given that there can be multiple locks applying at the same time.
Otherwise, the proposal sounds good to me.
Could be... I was thinking that the locks are kinda like a fallback
chain. That is, if you have the screen you also have system. If you
lose screen (notified via an event), you request system before the
device goes to sleep. If it's not possible to do things in that order,
then yes: we would need to return a list of the current locks.
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.
-- Mounir
Re: [whatwg] Proposal: Wake Lock API
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy to do with the tools the
platform already provides. The argument to support this feature in the
github issue was that it will prevent developers to forget releasing the
lock but I have a hard time believing that developers forgetting to
release a lock would use a timeout that is probably more painful and
error-prone.
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.
I think books UC is a good one - you don’t need wake lock to be kept
infinitely, you only need it to be active for 2-5 minutes, depending on how
fast you read. Then you interact with screen, turning the page.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
You might want something like:
partial interface WakeLock {
readonly attribute WakeLockType[] currentLocks;
};
Given that there can be multiple locks applying at the same time.
Otherwise, the proposal sounds good to me.
Could be... I was thinking that the locks are kinda like a fallback
chain. That is, if you have the screen you also have system. If you
lose screen (notified via an event), you request system before the
device goes to sleep. If it's not possible to do things in that order,
then yes: we would need to return a list of the current locks.
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.
I think Marcos meant that keeping the screen leads to keeping cpu, but not vice
versa.
— Mounir
Thanks,
Ilya
Re: [whatwg] Proposal: Wake Lock API
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: http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books 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.
Re: [whatwg] Proposal: Wake Lock API
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
### Timeouts
We are thinking of adding a dictionary to hint at the system the amount
of time it should hold the lock for (in ms). So, then the developer can
express holding the lock for 5 minutes (e.g., ebook case, instead of
having to bind a whole bunch of listeners and constantly having to
request the wake lock). This would allow the UA to add whatever time the
developer requested to its normal wake lock timer + additional time the
developer might want. If the timeout is less than the default timeout, it
can just be ignored.
```
dictionary WakeLockOptions{
unsigned long timeout;
}
```
For example:
```
//I only need this for ~5 mins here.
var options = {timeout: 1000 * 60 * 5};
navigator.wakeLock.request(display, options);
```
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy to do with the tools the
platform already provides. The argument to support this feature in the
github issue was that it will prevent developers to forget releasing the
lock but I have a hard time believing that developers forgetting to
release a lock would use a timeout that is probably more painful and
error-prone.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
You might want something like:
partial interface WakeLock {
readonly attribute WakeLockType[] currentLocks;
};
Given that there can be multiple locks applying at the same time.
Otherwise, the proposal sounds good to me.
-- Mounir
Re: [whatwg] Proposal: Wake Lock API
On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
I do not think we should have this timeout option. That sounds like a
very week use case and something fairly easy to do with the tools the
platform already provides. The argument to support this feature in the
github issue was that it will prevent developers to forget releasing the
lock but I have a hard time believing that developers forgetting to
release a lock would use a timeout that is probably more painful and
error-prone.
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.
I'm happy to see how people make due without it, and if we find too many
problems we can always add this later.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
You might want something like:
partial interface WakeLock {
readonly attribute WakeLockType[] currentLocks;
};
Given that there can be multiple locks applying at the same time.
Otherwise, the proposal sounds good to me.
Could be... I was thinking that the locks are kinda like a fallback chain. That
is, if you have the screen you also have system. If you lose screen
(notified via an event), you request system before the device goes to sleep.
If it's not possible to do things in that order, then yes: we would need to
return a list of the current locks.
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.
Re: [whatwg] Proposal: Wake Lock API
Should the lock automatically be released if the user switches to a
different tab or somehow makes the content unviewable? Should the web
content know about this, or should it just silently think the lock is still
being held? This might affect the timeout situation. It would be strange to
be unable to lock or suspend due to some random map embedded in a Yelp page
somewhere taking a lock.
What about for cases like laptops where the user can force a suspend, like
closing the lid? If the system is configured to lock or suspend the
machine, should this prevent it? Are there any tasks like instant messaging
where users might want to have it inhibit suspend, and the user can still
be notified of it because the system might make a sound? Should the web
content be aware of this as well?
I'm at least happy that the web doesn't have the burning a CD task that
we had to deal with with our desktop. :) That was a messy set of edge cases
to deal with.
On Tue, Jul 15, 2014 at 3:21 PM, Marcos Caceres w...@marcosc.com wrote:
## Use cases
A website wants the prevent a device from entering a power-saving state to
allow a user to complete a task where it's not practical for the user to
touch the screen (e.g., a maps application while driving, a VR headset like
Cardboard).
A website needs to be able to complete a task, but without requiring the
user to keep the screen on (e.g., importing and processing a bunch of
contacts). Having a wake lock on the system would allow the user to turn
off the screen, while allowing a webpage (or worker) to continue processing
some data in the background.
A complete list of use and abuse cases can be found at [1].
## Workarounds
There is some evidence that …Developers are resorting to hacks like
playing hidden videos to prevent the screen from sleeping. [2]
## Why now?
There are lots of applications on the Web that would benefit from this
feature. E.g., maps, games, cooking websites, ebooks, and sites that stream
non-video content in real time (e.g., sports scores). Also, both Google and
Mozilla are looking into VR, and they will likely need this (see [2]). See
[1] for list of applications that rely on this feature in other platforms.
Other platforms that already support this kind of feature: iOS, Android,
Firefox OS, Windows mobile, and Tizen.
# Proposal:
```
partial interface Navigator {
attribute WakeLock wakeLock;
}
interface WakeLock{
promise request(WakeLockType type);
void release(WakeLockType type);
}
enum WakeLockType{ system, display }
```
## Example
//lock display when the recipe is showing:
$( #recipe ).on( show, function(){
navigator.wakeLock.request(display).then(haveFun, boo)
} );
//release lock:
$( #recipe ).on( hide, function(){
navigator.wakeLock.release(display)
} );
## Optional enhancements
### Timeouts
We are thinking of adding a dictionary to hint at the system the amount of
time it should hold the lock for (in ms). So, then the developer can
express holding the lock for 5 minutes (e.g., ebook case, instead of having
to bind a whole bunch of listeners and constantly having to request the
wake lock). This would allow the UA to add whatever time the developer
requested to its normal wake lock timer + additional time the developer
might want. If the timeout is less than the default timeout, it can just be
ignored.
```
dictionary WakeLockOptions{
unsigned long timeout;
}
```
For example:
```
//I only need this for ~5 mins here.
var options = {timeout: 1000 * 60 * 5};
navigator.wakeLock.request(display, options);
```
### Events
It might be necessary for applications to be notified, via an event, if
they've lost a lock after one was granted to it.
### Check if lock is already set
It might be useful to also have a way of checking if a lock is already
set:
``
readonly attribute WakeLockType? lockType
```
Appreciate any feedback on the design and help with the security model.
[1] https://w3c-webmob.github.io/wake-lock-use-cases/
[2] https://code.google.com/p/chromium/issues/detail?id=386255
--
Jasper
Re: [whatwg] Proposal: Wake Lock API
On July 15, 2014 at 3:31:32 PM, Jasper St. Pierre (jstpie...@mecheye.net) wrote: Should the lock automatically be released if the user switches to a different tab or somehow makes the content unviewable? Yes. But it could be automatically reapplied once the user switches back to the tab/window. This could happen transparently. Should the web content know about this, or should it just silently think the lock is still being held? Ideally, it should just be silent. This might affect the timeout situation. It would be strange to be unable to lock or suspend due to some random map embedded in a Yelp page somewhere taking a lock. The locks are fairly soft, at last for screen. But yes, for system locks that would suck. We might need to limit those somehow. What about for cases like laptops where the user can force a suspend, like closing the lid? If the system is configured to lock or suspend the machine, should this prevent it? No, in this case it could be notified that it has lost the lock. Are there any tasks like instant messaging where users might want to have it inhibit suspend, and the user can still be notified of it because the system might make a sound? Should the web content be aware of this as well? I think that's a different use case: That could be better suited for push notifications + service workers + the notification API. I'm at least happy that the web doesn't have the burning a CD task that we had to deal with with our desktop. :) That was a messy set of edge cases to deal with. Heh, I'm sure similar cases will come up in the future (e.g., 3D printing over serial port API).
