We did talk about these solutions and neither is desirable as they adds significant complexity to the System app internal, and the cost of reviewing every future patch.
(We even went to not-so-crazy ideas like simply overwrite window.Audio with our wrap) That's why a platform API is better and uniform IMHO. On Tue, May 5, 2015 at 4:24 AM, Jonas Sicking <[email protected]> wrote: > Technically the system app *can* manage its own sound. By using > .volume and .pause()/.play() functions on the <audio> elements > directly. > > I understand that it adds extra complexity to the code to manage all > other audio using the Browser API, but the system app audio using the > <audio> API. > > One potential solution here would be to write a JS library which wraps > both the <audio> API and the Browser API and exposes the same API for > managing both. That might be less work than adding more platform APIs > here? > > / Jonas > > > On Mon, May 4, 2015 at 2:31 AM, Dominic Kuo <[email protected]> wrote: >> 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-webapi mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-webapi _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
