Comment 51 for bug 604635

IMO, and based on my experience with pushState, composition is not an important consideration in these APIs. If you want to compose the API, as with the call waiting example, then it's trivial to write a wrapper.

There's a cost to asking everyone to carry around these lock objects, and to understand what the heck they are.

(Note also that there are a variety of ways you might want to write this reentrant API. You might want to carry around lock objects, or you might want to count the number of calls to lock() and unlock(). It's hard to pick just one.)

> 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 this is a fair point.

The simplest API views the screen lock as a switch. It starts off as unlocked. You can flip the switch to locked, and you can flip it back. How can we design an API which reflects this unambiguously?

Maybe we can do (with different names)

  navigator.requestWakeState("screenOn")
  navigator.releaseWakeState("screenOn")

If we picked good names, it could be clear that you're releasing something you requested; that is, you're flipping a switch.