Comment 105 for bug 604635

Hi guys, finally caught up on this bug, and unsurprisingly I have lots of opinions :)

First off, let's talk about what we want applications to be able to do:

The most basic use-case is for a video-playing app (or webpage) to want to disable the "screen saver" from starting while the user is watching the video. And by "screen saver" I mean the normal screen saver on desktop, and dimming/turning off the screen on mobile.

For this use-case, the user pressing the "turn off" button should clearly override the lock. However it shouldn't release the lock (or at least it doesn't need to)!

The second use-case would be wanting to keep the CPU going even when the user "sleeps" the device. One situation that I hit very often is when in a camera app. Right after taking a picture I tend to want to hit the sleep button right away and put the camera in my pocket. But the app likely will want to JPEG encode (or hipstamatic reformat) the picture and save it to disk.

Another example here is wanting to run a long-running calculation. It's great if the user can start such a task, press the "sleep" button and have the device go to sleep as soon as the task is done. This is something I have wished for many times when compiling firefox and then shutting my laptop.

Here too the user can override the lock by force-closing the app or by completely shutting down the device. Possibly in both these instances we'll want to give the app a second or two to finish up whatever it's doing if it's holding the lock though.

The third use-case that people has mentioned is wanting to keep different types of network connectivity (wifi/3g/2g) alive. I don't yet fully understand this use-case though, so a few questions:
* Can someone provide an example of what type of app needs this.
* Would the connection be held open even if the user presses the "sleep" button. (I presume yes?)
* Do we need fine-grained control over which connectivity should be kept alive? I.e. does the app need to be able to say "hold 3g alive" or "hold wifi alive". Or is it enough to be able to say "hold data-connectivity alive". The latter seems more convenient for pages. The question is if it supports all use-cases.
* Would it be allowed to switch from 3g to wifi when the lock is held? Keeping in mind that this would likely switch IP number and drop all current connections. Or is the idea that as long as the lock is held we try not to switch IP number (which might prevent us from upgrading from 2g to 3g for example, not sure).

A different type of use-case that has been discussed is "apps with screen-management permission". While I could see having apps which overrode how/when/how-much we dim the screen, I don't think this is a urgent use-case. I.e. I'd rather not worry about that now. We should certainly allow apps to have access to settings, and have settings for how quickly and how much we dim the screen, but the actual interacting directly with the screen should IMO for now be done just by gaia/gecko.

Which brings me to the discussion about rings. The way I look at it gaia and gecko should have the same amount of trust. I.e. I would consider gaia+gecko to make up the "platform". The platform has system level privileges and is trusted to do anything and relied on to do things correctly.

Again, long term I think we should allow applications to replace parts of the platform. I.e. it'd be cool with applications which can replace the status bar, the virtual keyboard, the lock-screen, the "desktop" etc. But I don't think we should worry about that for now. iOS doesn't allow any of that, and Android allows little, if any, of it.

I absolutely think we should do those types of things, but I think we should keep such APIs separate, and I think we should worry about it once we have more of the "normal" apps pieces in place since normal apps will be the much more common use case and so should be what is the highest priority for the API design.

As for using CSS to screen-locking. I agree that while it would let us do elegant solutions for a few use-cases, but it wouldn't cover enough of them. So while we could do:

video:-moz-full-screen {
  screen-saver: none;
}

we don't have a pseudo-class for paused videos afaik. So what you'd really want to do:

video:-moz-full-screen:not(:paused) {
  screen-saver: none;
}

doesn't work. And I often watch video not in full-screen, in which case the above wouldn't be enough.

I'd rather focus on a JS-API which can solve all our use-cases for now, and add something like CSS-support later if developers ask for it.