Comment 126 for bug 604635

Revision history for this message
In , Kchen-d (kchen-d) wrote :

(In reply to Justin Lebar [:jlebar] from comment #91)
> > Some wake locks should probably be canceled earlier than that -- for example, the screen wake lock
> > should probably be canceled if the document which requested the lock becomes invisible (e.g., I
> > switch away from that tab).
>
> Actually, this is a bit more complex than I thought.
>
> The trick is, we want all policy to live in Gaia. (Where by "Gaia", I mean
> Gaia or an alternative.) That should include the meaning of the wake-lock
> topics.
>
> So in order for this to work, isWakeLockHeld() needs to return some
> information about the documents holding the relevant wake lock. Maybe the
> info is just [not held, held by at least one visible document, held only by
> invisible documents].

Should we care whether the page is invisible or not? I think the app should do the housekeeping by itself, acquire lock onload and possibly release the lock when it becomes invisible.

For example the Music app might want to keep the audio and cpu on when it is running in the background or even when the screen is turned off.