Hi folks, Recently, some of the b2g folks are refactoring the audio channel service in [1], what we do is using the new broswer api [2] to allow/deny the audio channels, then wrap up those logic we used in gecko then re-implement it in gaia. It's a sub-module [3] directly in the System app, in theory it's capable of managing any iframe/app's audio channel which created under the System app.
The problem we encountered is, we use some audio elements to play sounds in the System app, like the notification, screen reader, ringtones..., this means we also need to manage the System app's audio channels. The trivial way is to do it in its parent(shell.js), it can be done but imagine that, there will be duplicate/extra logic to manage the System app's audio channels, just like those we implemented for all the gaia apps and seems strange for us. So we are wondering that, does it make sense to expose the browser api reference to the System app itself? so that the the System app is able to manipulate its own browser api then manage its audio channels. Reason: the System app is unable to manage its own audio channels. (if we don't do it in shell.js) Proposal: the internal/certified app has some way to access the browser api then manipulate them. (Possibly in the future there might be some similar usages, the System app needs its browser api to manage things.) Any thoughts? (We are also discussing the alternative solution in [4] and feel free to give us some idea!) [1] Refactor Audio Channel Service: https://bugzilla.mozilla.org/show_bug.cgi?id=1089539 [2] Audio Channel Browser api: https://bugzilla.mozilla.org/show_bug.cgi?id=1113086 [3] Audio Channel Service: https://bugzilla.mozilla.org/show_bug.cgi?id=1100822 [4] Manage the System app's audio channels: https://bugzilla.mozilla.org/show_bug.cgi?id=1157140 Thanks, - Dominic
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
