Comment 88 for bug 604635

> This also means web developers (and us implementers!) don't need to remember to
> unlock() or (re)enableScreenSaver() when the screen-saver-disabled document has
> been gc'd; it happens automatically when the rule no longer applies.

When a document is GC'ed (if not before), Gecko will automatically release its wake locks, automatically.

A CSS property for this doesn't make much sense to me, because "screen-saver enabled" applies to the whole screen, not an individual element. Maybe others disagree.

And then there's the whole question of deciding who gets precedence if one element on the page has screen-saver: enabled and another has screen-saver: disabled.

It's only when you remove the element which has screen-saver:enabled from the DOM that you get any benefit from this. But what if your full-screen video is paused? Shouldn't you allow the screen-saver to come on? So I don't know how much effort this CSS property would really save.

> It's not really a question of simplicity, but API semantics. Let's nail that down first.

What I mean is, it's a much simpler API if pages don't have to listen for "wake lock going away" and explicitly release the wake lock. Simpler APIs are preferable to complex APIs, because there's less room for error, and every mistake which can be made will be made, and by many pages.

I think the API should have advisory wake-locks; that is, when I call screen.enabled = false, the screen turns off, period.

I can't think of a situation where it makes sense for us to grant a page or app the ability to keep the power manager from turning something off. The power manager will act as the user's agent, and when the user wants the screen or radio turned off, we should turn it off.

In the case that we notify the wake lock that it's going away, we're not really giving the page an opportunity to override the screen-turn-off action. It either releases its lock or it dies. Much better would be simply notifying the page that its wake lock has been revoked.

I think most of that notification functionality is already there, at least indirectly. A page can already tell when it's no longer visible (either due to tab switching or the screen turning off). And the network API will let pages tell when the network goes up or down, right?

I suspect that 99% of pages won't care when their wake lock is revoked, so I'm not sure we need to build revocation directly into the API. (It complicates things -- if my screen wake lock is revoked, and the user turns the screen back on, do I have to re-register my lock, for example? Again, complexity is to be avoided because it leads to mistakes in content.) But we should make sure that pages can at least understand the status of the network/display, for sure.