I found three wake locks acquired in Gecko: * "DOM_Fullscreen" * "Playing_media", and * "nsNPAPIPluginInstance". It looks like the only place that listens to these wake locks is GeckoApp.java, which keeps the screen alive whenever any wake lock is held. I assume the intent in these three places is to keep the screen alive whenever we're in full-screen mode, playing media, or have a plugin alive. This is not correct use of the wake lock API. If you want to keep the screen alive, you should acquire the "screen" wake lock. The code in GeckoApp.java should then tell the system not to shut off the screen iff the "screen" wake lock is held. Whether any other wake lock is held should not affect whether the screen stays on. This is necessary because we use wake locks in B2G to indicate states other than "screen should stay alive." For example, we have a "cpu" wake lock which means "the CPU should stay alive, but the screen may turn off." The implementation of wake locks in GeckoApp.java precludes this interpretation. Separately, if I understand the code, nsHTMLMediaElement acquires the "Playing_media" whenever an audio or video element is playing. It doesn't seem to me that we should keep the screen alive if we're playing audio. And indeed, some websites are now using <video> elements for small animations; I'm not sure it's correct to assume that any not-paused <video> is worth keeping the screen on for.

Is there documentation somewhere on the correct use of the wake lock API?

(In reply to Chris Double (:doublec) from comment #1) > Is there documentation somewhere on the correct use of the wake lock API? Not really. The idea was that content would acquire wake locks (via navigator.acquireWakeLock) and then Gaia would react to those wake locks (via the wake lock listeners on mozpower). Gecko doesn't define the meaning of any wake lock names at the moment. The motivation for this design was the following situation: The "power" button on the B2G phone is handled by Gaia; to Gecko it's just a key. If the user presses the power button while the "screen" wake lock is held, we still want the screen to turn off. OTOH Gaia is also responsible for turning the screen off after an idle timeout. To Gecko, there's no difference between Gaia turning off the screen due to idle and Gaia turning off the screen due to the power button. And we decided that means that Gaia needs to know whether the screen wake lock is held, so it can avoid turning off the screen on idle when a screen wake lock is held. So we decided that (at least on B2G), wake locks wouldn't have any defined semantics in Gecko and would be handled entirely in Gaia.

Ok, thanks for the explanation!

Any chance of getting navigator.requestWakeLock("cpu") to acquire a CPU wakelock on Android as part of this fix? There is some documentation at https://wiki.mozilla.org/WebAPI/ResourceLockAPI saying that "no locks except the screen lock is honored for non-installed pages", so perhaps it should be allowed for pages that *are* installed as apps?