Closed Bug 851021 Opened 12 years ago Closed 7 years ago

Split mozPower API

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: frsela, Unassigned)

References

Details

The navigator.mozPower API (https://developer.mozilla.org/en-US/docs/DOM/window.navigator.mozPower) is only allowed to certified apps. But the use of screenBrightness is not as critical as power off the device. I suggest to split the API in two based on critical areas. As an example, I needed this to implement a really trivial uncritical flashlight app (https://github.com/frsela/flashlight_webapp) and I needed to define it as "certified" !
The initial idea was to aggregate power control api of devices to one place. But it has screen control so far. I think we could 1) Move screenBrightness and screenEnabled back to window.screen or other interfaces 2) Define finer control of power related permissions
> But the use of screenBrightness is not as critical as power off the device. What are you trying to accomplish by allowing apps to directly read and write the screen brightness? My thought when we designed this API was that if we wanted to give apps the ability to e.g. keep the screen from dimming, they could use a wake lock. I think the OS should be responsible for monitoring the ambient light sensor and ensuring that the screen stays at a reasonable brightness, so I am hesitant to expose this API to apps. Also, if we did, we'd probably have to give Gaia the ability to notice when an app changed this value, so Gaia could change it back when the app closed. That is, this is a much more complex feature request than it seems!
> As an example, I needed this to implement a really trivial uncritical flashlight app > (https://github.com/frsela/flashlight_webapp) and I needed to define it as "certified" ! Right, this will probably mess up Gaia's handling of the screen brightness! I'd be OK having a "screen-max-brightness" screen wake lock.
(In reply to Justin Lebar [:jlebar] from comment #2) > > But the use of screenBrightness is not as critical as power off the device. > > What are you trying to accomplish by allowing apps to directly read and > write the screen brightness? > As an trivial example, a simple flashlight app :) You need the maximum amount of light available ;) > My thought when we designed this API was that if we wanted to give apps the > ability to e.g. keep the screen from dimming, they could use a wake lock. > Agree using a wake lock and allow increase dimming is ok. > I think the OS should be responsible for monitoring the ambient light sensor > and ensuring that the screen stays at a reasonable brightness, so I am agree, but some apps could need this kind of features. > hesitant to expose this API to apps. Also, if we did, we'd probably have to > give Gaia the ability to notice when an app changed this value, so Gaia > could change it back when the app closed. That is, this is a much more > complex feature request than it seems! Yep, as soon as the app is closed, the screen light should return to normal WoW
(In reply to Justin Lebar [:jlebar] from comment #3) > > As an example, I needed this to implement a really trivial uncritical flashlight app > > (https://github.com/frsela/flashlight_webapp) and I needed to define it as "certified" ! > > Right, this will probably mess up Gaia's handling of the screen brightness! > > I'd be OK having a "screen-max-brightness" screen wake lock. Cool ;)
So I have a different use case for this, but it might be possible to use background services when they are available. I was making a demo app for a paper that acts as a virtual tripwire, it uses the proximity API. Now I would like to make it look like the phone is off, so I would like to request for the screen to turn off fully until the user taps on it again. I know turning of the screen fully is critical, but maybe it would work if the API was made in a way that any tap would re-enable the screen?
Depends on: 1382955
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.