Confirmed users
53
edits
No edit summary |
|||
Line 57: | Line 57: | ||
== System and Browser API changes == | == System and Browser API changes == | ||
We need to add settings for controlling the volume of | We need to add settings for controlling the volume and the mute to any iframe mozbrowser. | ||
The proposal is to add this set of new properties to the browserAPI (for simplicity in webIDL): | |||
interface BrowserAPI { | |||
// With this it's possible to mute all the MediaElement for this mozbrowser iframe. | |||
attribute boolean audioMuted; | |||
// range: 0.0 to 1.0 - a custom volume | |||
attribute double audioVolume; | |||
// list of active audio channels | |||
readonly attribute DOMString[] activeAudioChannels; | |||
// if this app actually playing? | |||
readonly attribute boolean audioActive; | |||
// horrible name :( | |||
// when this attribute is set to true, any normal channel will be 'converted' | |||
// to content channel. This fixes the problem of the visibility. | |||
// Task of the system app is to set this boolean to true before changing the visibility to false | |||
// for the foreground app. Implementing this, we can revert all the hacks we implemented for the | |||
// visibility and normal channels... | |||
attribute boolean normalAudioChannelToContent; | |||
} | |||
In addition we want to emit events when activeAudioChannels and audioActive attributes change. | |||
All of these changes are meant to be built on top of the existing AudioChannelService. Doing that we keep the logic in gecko, but we allow custom settings: | |||
1. the browser can let play websites as such as spotify, grooveshark and so also when the device is locked, setting normalAudioChannelToContent to true. | |||
2. the system app can mark the foreground app, setting normalAudioChannelToContent to true before changing the visibility | |||
3. the settings app can have configurations ad-hoc for the audio management and apps | |||
== Settings == | == Settings == |