(In reply to Chris Pearce, Mozilla Corporation (:cpearce) from comment #52)
> Is the "wakelock" API exposed to content on desktop Firefox? It seems very
> phone/B2G specific at the moment.
>
Yes, it would be exposed on all platforms.
> Strictly from a desktop/content perspective, it would be handy if the API to
> disable the screensaver was exposed as a simple CSS property, much like the
> cursor:none CSS property.
>
Interesting idea!
> This also means web developers (and us implementers!) don't need to remember
> to unlock() or (re)enableScreenSaver() when the screen-saver-disabled
> document has been gc'd; it happens automatically when the rule no longer
> applies.
The problem is if there are conflicting rules. What happens if one embedded iframe has a "screen-saver: none" rule but another has "screen-saver: enabled"? The wakelock primitive makes the semantics of that clear. We could arbitrarily define which wins for a CSS rule, if we go that route.
(In reply to Chris Pearce, Mozilla Corporation (:cpearce) from comment #52)
> Is the "wakelock" API exposed to content on desktop Firefox? It seems very
> phone/B2G specific at the moment.
>
Yes, it would be exposed on all platforms.
> Strictly from a desktop/content perspective, it would be handy if the API to
> disable the screensaver was exposed as a simple CSS property, much like the
> cursor:none CSS property.
>
Interesting idea!
> This also means web developers (and us implementers!) don't need to remember nSaver( ) when the screen- saver-disabled
> to unlock() or (re)enableScree
> document has been gc'd; it happens automatically when the rule no longer
> applies.
The problem is if there are conflicting rules. What happens if one embedded iframe has a "screen-saver: none" rule but another has "screen-saver: enabled"? The wakelock primitive makes the semantics of that clear. We could arbitrarily define which wins for a CSS rule, if we go that route.