On Fri, Jul 24, 2015 at 5:55 AM, Michael Henretty <mhenre...@mozilla.com> wrote: > > On Thu, Jul 23, 2015 at 12:32 AM, Tim Guan-tin Chien <timdr...@mozilla.com> > wrote: >> >> The one big exception here is the Browser API proxies. Sometimes >> System app would need to access the Browser API methods exposed to >> it's own embedder. Unless we implement some kind of >> |navigator.mozControlMyOwnBrowserFrame| API to host these methods, we >> would be still rely on shell.js to use them, for now. I can send out >> another proposal if people are interested. > > > Can you explain this a little more? I'm not sure what this means. >
Take AudioChannel management for instance. The latest reversion will allow System app to mute/pause audio from a given app frame, and the methods to do so are attached on the mozbrowser iframe instance. Given the design, System are prevented to manage it's own audio from various components. The current fix here is to allow System to access the audio managing methods of it's own hosting frame by wiring them to mozChromeEvents/mozContentEvents. Tim _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
