Re: Standby API Specification Proposal

On May 28, 2014 at 8:37:07 AM, Frederick Hirsch (w3c@fjhirsch.com) wrote:
> > Regarding the three proposals on the list related to a possible  
> standby API [1], I think what was noted in the Chromium log is important  
> [2]:
>  
> "Applications can receive other forms of input than touch, whereas  
> only touch will prevent the device from sleeping after N seconds”  
>  
> 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). 

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

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

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();
  }
}

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

Received on Wednesday, 28 May 2014 12:55:32 UTC