Exposing the browser api reference to the internal/certified apps(eg. System app) themselves?

[Dominic Kuo]

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

[Jonas Sicking]

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

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Tim Guan-tin Chien]

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.

[Kan-Ru Chen (陳侃如)]

Tim Guan-tin Chien <timd...@mozilla.com> writes:

> 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.

Alternatively, how about wrapping the audio playing part of system app
in a separated browser-element? Then you would control the audio just
like controlling other apps.

Kanru