Re: [whatwg] Preventing wake lock leaks with DOM nodes
This is what the attached and detached callbacks are for on custom elements. Someone can build an app-screenlock element that requests the lock when it's attached (added to the viewed document) and releases when it's detached (removed from the viewed document). There's no reason to complicate this API, developers have the primitives to do this already. On Mon, Aug 18, 2014 at 6:20 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 18, 2014 at 5:35 PM, Marcos Caceres w...@marcosc.com wrote: The reason I didn't make it a boolean was because of the IPC involved and because I wanted to support multiple types of locks without needing to add new attributes in the future (and if we need to add the complex stuff later). What's the problem with adding more attributes in the future? That said, I do think that a timeout for screen locks make sense, so a boolean wouldn't work. Though not as a timeout for when to release the lock, but rather as a minimum time I'd like to keep the screen awake as described at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297423.html / Jonas
Re: [whatwg] Preventing wake lock leaks with DOM nodes
On Mon, Aug 18, 2014 at 4:21 PM, Kornel Lesiński kor...@geekhood.net wrote: My biggest concern with the WakeLock API is that it's easy to forget (or fail) to release the lock. It's not a problem with the API per se, but a programming problem in general: resource management in non-trivial programs is hard. WakeLocks are especially problematic in this regard, as a leaked lock won't cause any immediate problems for the developer, so this type of bug can easily go unnoticed. So I think lifetime of WakeLocks needs to be attached to something visible to make failure to release the lock immediately obvious. In case of screen lock it's especially easy: the whole purpose of this lock is to keep something visible on screen, so we can require that something to be explicitly connected to the lock. For example if I were creating a widget that displays a presentation on the page, I could attach the screen lock to the canvas or svg element that holds the presentation: new navigator.ScreenLock(myCanvas); and if the canvas was removed from the document or hidden in any way, then the browser could turn the screen off as usual, and I wouldn't have to do anything! It's nearly impossible to forget to remove a visible DOM element from the document — the mistake is likely to be quite obviously visible. If screen lock lifetime was dependent on visibility of a DOM element, then it would also be very hard to leak the lock without noticing it! (that's a variant of wake-lock:display CSS proposal, but less explicitly dependent on CSS). Good, but you lose the ability to key the wake-lock to Selectors-exposed UA state (like video:playing), or directly to your app's own state (via some class that gets set/removed by your app at some point in its lifecycle). But if the CSS part is distasteful, I agree that this works reasonably well - there is *absolutely no reason* to screenlock based on an element that's not visible on screen. With CPU lock it's less clear cut. I think tying it to a notification may be a good idea. Alternatively, perhaps the lock itself could be an instance of the progress element that author is supposed to insert to the document? ;) Just pass a promise to the CpuLock constructor, and have it auto-release when the promise is settled? You'll generally be CPU-locking to wait for some operation to finish, and a lot of those types of operations vend promises these days (or will in the future). ~TJ
Re: [whatwg] Preventing wake lock leaks with DOM nodes
On Monday, August 18, 2014 at 7:21 PM, Kornel Lesiński wrote:
My biggest concern with the WakeLock API is that it's easy to forget (or
fail) to release the lock.
It's not a problem with the API per se, but a programming problem in general:
resource management in non-trivial programs is hard. WakeLocks are especially
problematic in this regard, as a leaked lock won't cause any immediate
problems for the developer, so this type of bug can easily go unnoticed.
Sure. At least on a mobile device, it's easy enough for the user to turn off
the screen (or just switch apps or browser tabs)... on laptops, it could be a
problem. However, MacOS (at least) is pretty good at telling users if an app is
eating too much battery. So this could be also handled at the system level.
So I think lifetime of WakeLocks needs to be attached to something visible to
make failure to release the lock immediately obvious.
In case of screen lock it's especially easy: the whole purpose of this lock
is to keep something visible on screen, so we can require that something to
be explicitly connected to the lock.
I think that would be nice, actually. It's at least a kinda workaround to
having to check if something is in the drawable area manually.
However, it still doesn't really deal with the case where the dev forgets to
release the lock. What is nicer is combining this with a timeout:
navigator.wakeLock.request(screen, {element: myCanvas, timeout: aFewMinutes});
That would be the most ideal solution for me personally. Just set it, and
forget it.
It's nearly impossible to forget to remove a visible DOM element from the
document — the mistake is likely to be quite obviously visible. If screen
lock lifetime was dependent on visibility of a DOM element, then it would
also be very hard to leak the lock without noticing it!
(that's a variant of wake-lock:display CSS proposal, but less explicitly
dependent on CSS).
Yes, absolutely. So long as CSS lacks some way to detect if something is
offscreen, it makes sense. The current ways of checking if an element is within
the viewport are quite expensive (bunch of jQuery plugins do this - and I think
they depend on the onscroll event).
With CPU lock it's less clear cut. I think tying it to a notification may be
a good idea.
Need to think about it.
Alternatively, perhaps the lock itself could be an instance of the progress
element that author is supposed to insert to the document? ;)
heh:) Yeah, need to think about that.
Re: [whatwg] Preventing wake lock leaks with DOM nodes
In general I feel this thread has taken a turn for the complex. Why don't we
just do what other platforms do, and provide a simple global request/release
mechanism (or toggleable Boolean property!), which developers can build on top
of? A lot of the ideas here seem to be trying to create the perfect,
developer-friendly, foolproof API. Some of them seem quite clever too, tying to
page visibility and the like. But all of them could be built, as libraries, on
top of a global request/release. That way users could get reference counting if
they want that, visibility-based locking if they want that, promise-based
locking if they want that, timeouts if they want those, or even just not do any
of those if their use case is simple enough that it doesn't warrant anything
more complicated than what they are already doing on existing platforms.
We don't need to solve Hard Problems in Programming (TM) before we expose a
wake lock API. Leave that as a subsequent step, which users can do, while we
move on to exposing more missing platform capabilities
On Aug 18, 2014, at 19:52, Marcos Caceres w...@marcosc.com wrote:
On Monday, August 18, 2014 at 7:21 PM, Kornel Lesiński wrote:
My biggest concern with the WakeLock API is that it's easy to forget (or
fail) to release the lock.
It's not a problem with the API per se, but a programming problem in
general: resource management in non-trivial programs is hard. WakeLocks are
especially problematic in this regard, as a leaked lock won't cause any
immediate problems for the developer, so this type of bug can easily go
unnoticed.
Sure. At least on a mobile device, it's easy enough for the user to turn off
the screen (or just switch apps or browser tabs)... on laptops, it could be a
problem. However, MacOS (at least) is pretty good at telling users if an app
is eating too much battery. So this could be also handled at the system
level.
So I think lifetime of WakeLocks needs to be attached to something visible
to make failure to we release the lock immediately obvious.
In case of screen lock it's especially easy: the whole purpose of this lock
is to keep something visible on screen, so we can require that something to
be explicitly connected to the lock.
I think that would be nice, actually. It's at least a kinda workaround to
having to check if something is in the drawable area manually.
However, it still doesn't really deal with the case where the dev forgets to
release the lock. What is nicer is combining this with a timeout:
navigator.wakeLock.request(screen, {element: myCanvas, timeout:
aFewMinutes});
That would be the most ideal solution for me personally. Just set it, and
forget it.
It's nearly impossible to forget to remove a visible DOM element from the
document — the mistake is likely to be quite obviously visible. If screen
lock lifetime was dependent on visibility of a DOM element, then it would
also be very hard to leak the lock without noticing it!
(that's a variant of wake-lock:display CSS proposal, but less explicitly
dependent on CSS).
Yes, absolutely. So long as CSS lacks some way to detect if something is
offscreen, it makes sense. The current ways of checking if an element is
within the viewport are quite expensive (bunch of jQuery plugins do this -
and I think they depend on the onscroll event).
With CPU lock it's less clear cut. I think tying it to a notification may be
a good idea.
Need to think about it.
Alternatively, perhaps the lock itself could be an instance of the
progress element that author is supposed to insert to the document? ;)
heh:) Yeah, need to think about that.
Re: [whatwg] Preventing wake lock leaks with DOM nodes
On Mon, Aug 18, 2014 at 5:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: In general I feel this thread has taken a turn for the complex. Why don't we just do what other platforms do, and provide a simple global request/release mechanism (or toggleable Boolean property!), which developers can build on top of? A lot of the ideas here seem to be trying to create the perfect, developer-friendly, foolproof API. Some of them seem quite clever too, tying to page visibility and the like. But all of them could be built, as libraries, on top of a global request/release. That way users could get reference counting if they want that, visibility-based locking if they want that, promise-based locking if they want that, timeouts if they want those, or even just not do any of those if their use case is simple enough that it doesn't warrant anything more complicated than what they are already doing on existing platforms. We don't need to solve Hard Problems in Programming (TM) before we expose a wake lock API. Leave that as a subsequent step, which users can do, while we move on to exposing more missing platform capabilities Nope, doesn't work. You can't build anything more complex on top of a simple request/release (or a boolean, which is equivalent), because any other library can come along and screw with the lock. So, if we want this to be extensible, we still need to design it in a localized way so that you can have multiple independent locks. If we did that, we *could* then layer a visibility/promise-based thing on top as an auto-release mechanism for a specific lock. But you've still got to solve at least one problem correctly. ~TJ
Re: [whatwg] Preventing wake lock leaks with DOM nodes
On Monday, August 18, 2014 at 8:10 PM, Domenic Denicola wrote: In general I feel this thread has taken a turn for the complex. Why don't we just do what other platforms do, and provide a simple global request/release mechanism (or toggleable Boolean property!), which developers can build on top of? A lot of the ideas here seem to be trying to create the perfect, developer-friendly, foolproof API. Some of them seem quite clever too, tying to page visibility and the like. But all of them could be built, as libraries, on top of a global request/release. That way users could get reference counting if they want that, visibility-based locking if they want that, promise-based locking if they want that, timeouts if they want those, or even just not do any of those if their use case is simple enough that it doesn't warrant anything more complicated than what they are already doing on existing platforms. We don't need to solve Hard Problems in Programming (TM) before we expose a wake lock API. Leave that as a subsequent step, which users can do, while we move on to exposing more missing platform capabilities
Re: [whatwg] Preventing wake lock leaks with DOM nodes
(sorry, accidental send before!) On Monday, August 18, 2014 at 8:10 PM, Domenic Denicola wrote: In general I feel this thread has taken a turn for the complex. Why don't we just do what other platforms do, and provide a simple global request/release mechanism (or toggleable Boolean property!), which developers can build on top of? A lot of the ideas here seem to be trying to create the perfect, developer-friendly, foolproof API. Some of them seem quite clever too, tying to page visibility and the like. But all of them could be built, as libraries, on top of a global request/release. That way users could get reference counting if they want that, visibility-based locking if they want that, promise-based locking if they want that, timeouts if they want those, or even just not do any of those if their use case is simple enough that it doesn't warrant anything more complicated than what they are already doing on existing platforms. The reason I didn't make it a boolean was because of the IPC involved and because I wanted to support multiple types of locks without needing to add new attributes in the future (and if we need to add the complex stuff later). The request()/release() mechanism is well suited for that, IMO. And it's also fairly simple, even if it vends a promise. Admittedly, I could just make it a bunch of boolean attributes. The spec is kinda already designed to work that way (what lock is applied is just a flag, which is checked synchronously)... it's how `isHeld(lockType)` works. About tying it to visibility, and time, etc. Those are nice to have, but can certainly do without for now. We already dropped the timeout stuff from the original spec - but certainly a nice to have in the future. Having said that, if we know that this API is going to be used in conjunction with scroll events, then we know we are going to have potential battery eating problems (beyond just keeping the screen on). We don't need to solve Hard Problems in Programming (TM) before we expose a wake lock API. Leave that as a subsequent step, which users can do, while we move on to exposing more missing platform capabilities Yeah, certainly want to keep it as simple as possible. Just want to cover keeping the screen on for now.
Re: [whatwg] Preventing wake lock leaks with DOM nodes
On Mon, Aug 18, 2014 at 5:35 PM, Marcos Caceres w...@marcosc.com wrote: The reason I didn't make it a boolean was because of the IPC involved and because I wanted to support multiple types of locks without needing to add new attributes in the future (and if we need to add the complex stuff later). What's the problem with adding more attributes in the future? That said, I do think that a timeout for screen locks make sense, so a boolean wouldn't work. Though not as a timeout for when to release the lock, but rather as a minimum time I'd like to keep the screen awake as described at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297423.html / Jonas
