Re: Standby API Specification Proposal

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

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.

> I just assume people will just do this: 
> //Poke it, because you must never sleep!!! 
> setInterval(poke, 0); 

That's certainly a risk. 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.

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

> > Is it possible that the browser implementation could detect  
> > window refresh associated with video or games, thus obviating  
> > the need for use of an API entirely in some cases? (that still would  
> > not address the use case of viewing a recipe)
> 
> You could, like assuming requestAnimationFrame() or CSS animations
> could imply this. But it's a bit of an abuse of the API and would tie
> people to using some particular solution or another. That could become
> unpredictable and have unforeseen consequences that developers didn't
> expect ("wtf is causing the screen to stay on?"). It's better, IMO, to
> let developers just handle this and not add any magic.    

+1

Dom

Received on Wednesday, 28 May 2014 13:18:12 UTC