Re: Standby API Specification Proposal

On May 28, 2014 at 9:20:50 AM, Dominique Hazael-Massieux (dom@w3.org) wrote:
> Le mercredi 28 mai 2014 à 08:54 -0400, Marcos a écrit :
> > > I suggest that we should attempt to avoid the risk of apps requesting
> > > locks and then not freeing them due to programmer error or other
> > > error conditions. (One denial of service attack might be to disable
> > > screen sleep to either cause burn-in or battery drain..)
> >
> > I seriously don't see this as a real problem, as if one closes the app
> > or opens a different tab the lock no longer applies (i.e., this only
> > applies to foregrounded windows).
>  
> Agreed; more specifically, I think both proposals on the table have the
> same properties with regard to security.
>  
> > > it seems Dom’s poke proposal gets at the idea of allowing programmatic
> > > notice of input other than touch, avoiding the issue of locks
> >
> > Not sure I follow how it avoids the issue of locks? Not sure what
> > "locks" means in this context?
>  
> requestWakeLock makes it easy to forget to remove the lock; poke() makes
> it harder (the wake lock disappears as soon as you stop poking).

Sure, but poke() has the uncertainty of not knowing when you last poked and how long the poke lasts (5 seconds? 30 seconds? 1 min?). So you still need to manage state or setInterval(). Thus, you still end up with harmless, but useless, repetitive loop of method calls in blind hope that it has an effect. 

> Another aspect where managing lock will trip people up: if several
> distinct libraries try to manage it, they have to carefully manage the
> state to avoid unlocking someone else's lock.

That's author error, IMO. 

There are few use cases where you want anything but the most simple wake lock:

1. always on - e.g., a game
2. on per request - e.g., a recipe website. 

Can you think of other use cases?  

> > I just assume people will just do this:
> > //Poke it, because you must never sleep!!!
> > setInterval(poke, 0);
>  
> That's certainly a risk. 

I don't think that is a risk: That seems fairly logical because that's the only way to guarantee you will get what you mean with the API.   

> That said I think the mental model of replacing
> user interaction with a poke is easier to grasp than managing locks and
> states in asynchronous environments.

I'm biased, of course. But I find the other approach conceptually easier to deal with without resulting to setInterval() or hooking into event loops. We know that, for instance, hooking into onscroll and the like has a noticeable performance penalty. 

In your proposal you have:

document.querySelector("video").ontimeupdate = poke;

Which will potentially generate hundreds, if not thousands, of unnecessary event objects. To avoid that, you will still need to manage state. Like using `onvideostart`, `onvideoend`, and having a PokeManager written in JS that relies on setInterval, so to make sure you don't flood the system with events (specially on highly constrained environments... ok, I'm admittedly FUDing here, but `onscroll` remains a real problem and this potentially introduces new ones). 

I'm worried that poke() just makes it too easy to fall into traps like the above - because it's the logical way to use it as your own proposal's example shows. 

> > When what they want is:
> > screen.getWakeLock();
> >
> > //If the use leaves and comes back...
> > window.onfocus = () => {
> > //if we've lost the lock
> > if(screen.wakeLockState === "unlocked"){
> > screen.getWakeLock();
> > }
> > }
>  
> Hmm... My perspective was that losing focus on the tab would stop the
> screen wake lock implicitly (i.e. the screen would be free to dim / lock
> again), not that it would require the developer to re-request it. That
> seems like a recipe for bugs.

True. So yeah, would be nice if you just keep it once requested (even as you switch between tabs/windows/apps) - until one chooses to releaseWakeLock(). 

I still don't think that forgetting to release the wake lock is that big a deal, tho.

Received on Wednesday, 28 May 2014 16:16:17 UTC