Comment 46 for bug 604635

(In reply to Justin Lebar [:jlebar] from comment #14)
> Maybe we're actually talking about the same thing, Chris. In what I've been
> thinking, each document may "disableScreenSaver", and if any visible
> document has done this, then the screensaver doesn't show. So
> "disableScreenSaver" in some sense "locks out" the screensaver.
>

Yes, I don't think they're terribly different fundamentally. The difference is that a window is allowed (AFAICT) to call enableScreenSaver() before disableScreenSaver(), and we have to arbitrarily define preferring the screen-saver being disabled to enabled.

> This is similar to the lock-based API you proposed (I'll call this the
> reentrant API, since it acts like a reentrant lock). Each document may
> choose to lock out the screensaver, and if any visible document has done
> this, the screensaver doesn't show.
>

Gotcha, but to my eyes that's not too clear from the API. If my app successfully calls enableScreenSaver(), I would expect the power-save to be enabled. But that's not the case; I've only released my window's claim on preventing power-save.

> I think the non-reentrant solution is simpler for web authors. They don't
> have to worry about calling disable-screensaver more than once, and they
> don't have to worry about calling enable-screensaver too many times. Locks
> are hard; let's go shopping.
>

Let's compare use cases. I have in mind an API like |lock = navigator.requestWakeState("screenOn")| paired with |lock.release()|.

The simplest and almost certainly most common use case would be J. Webauthor locking the screen the whole time her game is loaded. In that case, it's
  navigator.requestWakeState("screenOn")
vs.
  navigator.disableScreenSaver()
I'd say no difference.

The next simplest case would be locking/unlocking on video play/pause, say. Then it's
  gLock = navigator.requestWakeState("screenOn")
  ...
  gLock.release()
vs.
  navigator.disableScreenSaver()
  ...
  navigator.enableScreenSaver()
I'd say a win for disable/enable, but IMHO requestWakeState isn't much added complexity.

Next up is the re-entrancy case that may not be terribly common. But one use case for that is a phone app that locks the screen whenever there's a call session. I would implement that by having some per call-session state.
  session1.lock = navigator.requestWakeState("screenOn")
  ...
    session2.lock = navigator.requestWakeState("screenOn")
    ...
    session2.release();
  ...
  session1.lock.release()
vs.
  navigator.disableScreenSaver()
  ++gNumDisables
  ...
    if (!--gNumDisables)
      navigator.disableScreenSaver()
  ...
  if (!--gNumDisables)
    navigator.disableScreenSaver()
I would say a win for requestWakeState.

> The only case I can think of where the reentrant style helps is when I'm
> trying to manage the screensaver bit and a piece of third-party code is also
> trying to manage the bit. I just question whether that's a real use-case.

I think we mostly agree on this. I can imagine some use cases, but my concern is it's not sanely possible to compose disable/enable, but fairly natural to compose requestWakeState.

IMHO disable/enable isn't really simpler than requestWakeState in the cases above, but in exchange for potential slight simplification we give up composability and extensibility. I don't think that's a good trade.