Comment 74 for bug 604635

> What happens if another privileged app sets screen.enabled = false?

Aha. We've hit upon the important point here. I think we might as well ask: What happens if another privileged app calls shutdown()?

To back up: I envision that there are three rough levels of privilege on the phone:

Ring 2) Web privilege.
Ring 1) App privilege. Apps likely have more privileges than web pages by default (larger local storage quota, able to raise notifications, etc.).
Ring 0) Platform privilege. This is what we've been calling "Gaia", with the understanding that Gaia proper is not the only envisioned consumer.
Ring -1) Gecko.

There's some granularity in rings 2 and 1 -- maybe this app can access the accelerometers but not GPS, for example.

But the main feature which distinguishes rings 2/1 from ring 0 is that ring 0 is as trusted as Gecko. We should be able to recover from a misbehaving ring 2/1 app, but misbehaving ring 0 code can break the phone (just as misbehaving Gecko code can).

> What happens if another privileged app sets screen.enabled = false? Should the power
> manager be notified of that?

Only platform privilege (ring 0) code can set |screen.enabled = false|. Nothing other than the power manager should touch screen.enabled, and we trust that other modules won't step on the power manager's toes. (We do this through code review, just as we would in Gecko.)

> For the power manager to implement "turn off screen when idle", it's going to have to
> know what the idle timeout is (settings permissions). OK. But it also needs to know
> when "system activity" happens, so that it can reset its idle timer. How will the
> power manager do that?

The power manager will ask Gecko to call it back when there's been X seconds of inactivity. This means exposing an API similar to Gecko's idle service to ring 0.

> As devil's advocate again, I might suggest having gecko manage idle timeouts, screen
> dimming, and screen-off, and send notifications (maybe intents) asking the content
> power manager to implement various animations.

This sounds like suggesting that we eliminate ring 0 and push that functionality into gecko.

In general, this kind of approach limits extensibility. One can extend the functionality only at the points we define.

For example, suppose Gaia wants to display a list of options when you press-and-hold the power button (shut down, restart, turn off screen, enter airplane mode). It sounds like in this model, we'd have to code into gecko a press-and-hold callback which Gaia would listen to. And then we'd need to enumerate, in Gecko, what things the callback is allowed to do -- in general, code can't ask to turn off the screen, so the callback would have to specify its choice through a return value or something, I guess. So you couldn't extend the callback to do something new (say, turn off wifi + bluetooth) without modifying Gecko.

Also, suppose you wanted to bring up one menu on short press-and-hold and a different menu on long press-and-hold, or bring up a special menu when both the volume and power buttons are held down. Again, you need to modify Gecko.

These use-cases aren't so compelling, but I hope the general idea of ring 0 JS code which handles this kind of thing is.