Comment 45 for bug 604635

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.

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.

The only difference AIUI between these two is that in the reentrant case, the document's 'lock the screensaver' bit becomes unset only if you call unlock() as many times as you've called lock(). In the non-reentrant case, a document's 'lock the screensaver' bit is unset as soon as you call enableScreenSaver once.

The interaction with other windows and iframes is exactly the same in both cases.

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.

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.