There are two main use cases I know of for such an API (1) Allow a "home screen" app to lock the screen and disable button input, turn off the display, listen for a "user tried to wake up" notification, and turn on the display + unlock the screen/buttons. (2) Allow games/dialer/etc. to prevent the display from going to sleep in the middle of something important. This API is quite exploitable, so needs to be privileged and not allowed by default. It's also vulnerable to accidental DoS, e.g. someone navigates away from a page that locked input but didn't set up a matching unlock, so the UA will need to make sure these things are automatically released. Could maybe fold into whatever provisions we already have for releasing things like keyboard-input focus on navigation.

This sounds interesting. As a first step, I'd be much more interested if things like "user triggers sleep button" would fire events so devs could have a short timeframe to do whatever they need to do (like when exiting iOS apps, they have a couple ms to save stuff). Something like "onbrowserpause". I think we have a separate ticket for this one though.

(In reply to Paul Bakaus from comment #1) > This sounds interesting. As a first step, I'd be much more interested if > things like "user triggers sleep button" would fire events so devs could > have a short timeframe to do whatever they need to do (like when exiting iOS > apps, they have a couple ms to save stuff). Something like "onbrowserpause". > I think we have a separate ticket for this one though. I like the idea of an "onBrowserPause" and "onBrowserResume" events, similar to how many mobile devices handle such events (Windows Phone, Android, and iOS, to name a few). However, I'm not sure if we need to "prevent" sleeping. If there's no input after X amount of time, the device usually sleeps. In what instance would somebody *not* want that to happen? Unless a video is playing, in which case browsers usually can detect that behavior, and react appropriately. This is something that could be too easily abused. The only addition I think that we should implement are the pause/resume events that Paul suggested.

(In reply to Paul Bakaus from comment #1) > This sounds interesting. As a first step, I'd be much more interested if > things like "user triggers sleep button" would fire events so devs could > have a short timeframe to do whatever they need to do (like when exiting iOS > apps, they have a couple ms to save stuff). Something like "onbrowserpause". > I think we have a separate ticket for this one though. Sorry, I just checked, bug #674701 basically wants the same thing.

> (2) Allow games/dialer/etc. to prevent the display from going to sleep in the middle of something > important. This is orthogonal; let's do it separately.

(In reply to Justin Lebar [:jlebar] from comment #5) > > (2) Allow games/dialer/etc. to prevent the display from going to sleep in the middle of something > > important. > > This is orthogonal; let's do it separately. If you open a bug for power management, could you mention it here? (or just clone this one)

Filed bug 697132.

assinged to me for sec action to schedule a meeting

This work is covered by other bugs -> WFM. Reopen if these other pieces don't surface or don't meet the original report.

dveditz - clee closed the secreview bug as invalid, do we still need to do any kind of review here?

This got chopped up into other APIs/bugs and covered there.