STR: 1. Launch Browser App 2. Go to Youtube or CNN 3. Watch a video on Youtube or CNN Actual: - User cannot play a video on Youtube or CNN Expected: - User can watch a video on Youtube or CNN

Hi Josh, This issue can be reproduced in Nexus 5 (TV build). Thank you

Hi Cynthia, Can you provide a build which cause the problem to Blake? Thanks!

Hi Blake, Could you help to find someone who can help check? Thanks! Device Nexus5 Build ID 20150917101726 Gaia Revision 46f54ba279858b677793f78b7465b3a82f799eef Gaia Date 2015-09-17 00:49:40 Gecko Revision n/a Gecko Version 43.0a1 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150721.211608 Firmware Date Tue Jul 21 21:16:23 EDT 2015 Bootloader HHZ12f

Hi Cynthia, Can this be reproduced by non-TV version?

Hi Blake, This issue cannot be reproduced by non-TV version. Thanks! (In reply to Blake Wu [:bwu][:blakewu] from comment #5) > Hi Cynthia, > Can this be reproduced by non-TV version?

Hi Kilik, Could you please take a look at this issue if you have time? Thank you.

Hi Cynthia, I'm kinda stuck in refactoring video sink stuff, I'll ask James for help. Hi James, could you help me investigate this issue ? I've got the devices. You can have a look on it. Thanks

OK, I will try it on b2g desktop for TV build first to see if I can reproduce this issue.

We can reproduce this issue on b2g desktop TV build. But if you press the |mute| icon then refresh. The video can be played normally. If you press |unmute| when playing, the playback will stop immediately.

Currently we can set pref("dom.audiochannel.mutedByDefault", true); to false to avoid this issue occur both on B2G desktop for TV and Nexus5 for TV build. The root cause is that the AudioChannel policy has not back-ported yet on TV's system app(2.1). If finish porting, this issue should be fixed.

HTMLMediaElement::NotifyAudioChannelAgent(...) { mAudioChannelAgent->NotifyStartedPlaying(notify, &volume, &muted); will get the muted value from pref("dom.audiochannel.mutedByDefault", true); If mutedByDefault == true, it will fire a event to system app and wait for system app to callback for resuming the playback. If system app did not handle the event and never response the callback, the playback will block forever. If TV's system app is back-ported, this issue should be fixed.

So here is the actual problem: On TV, Browser is an app (different from phone which is part of System app), using mozbrowsr-iframe embedded by System app. Browser app uses mozbrowsr-iframe embeds other web pages. Following the architecture of audio channel control, the audiochannelstatechanged event from web content (CNN website, in this case) and other events should be handled by Browser app. Similar cases like Youtube app embeds youtube site, Marketplace app embeds Marketplaces site, ... etc. It's common in FxOS to have nested (3-layer or more) mozbrowser-iframe to load a video content, but we can't reply on a 3rd party app correctly managing audio channel policy. It looks like we need to tweak the whole mechanism a bit. We haven't had a concrete and proper solution yet, so I filed bug 1214148 to follow-up. In this bug, we want a quick hack to address this problem. Since System app is the central control of all audio channel change events, we could bypass the middle layer of mozbroswer-iframes. Therefore the event target will be always an iframe element owned by System app, no matter the requesting video element is embedded in the window of this iframe or its child iframe. System app controls the app and its children, as a whole. :baku, we had a offline discussion with the Audio team in Taipei, may I have your opinion? Thanks. :) @Kanru, could you comment here on the implementation details of tracing mozbrowser iframe arch in OOP and non-OOP cases? Thanks!

So it seems that we are going to fix bug 1214148 for a more correct solution instead of workaround here. @Josh, this bug is equivalent to bug 1214148, we should set it a dup, but I keep it open in case :baku couldn't fixed that bug in 2.5 timeline.

(In reply to Evelyn Hung [:evelyn] from comment #14) > So it seems that we are going to fix bug 1214148 for a more correct solution > instead of workaround here. > > @Josh, this bug is equivalent to bug 1214148, we should set it a dup, but I > keep it open in case :baku couldn't fixed that bug in 2.5 timeline. Since bug 1214148 is set to 2.5 blocker and it would be better not to have two 2.5 blockers pointing to the same problem, I would like to close this one as a duplicate bug. Evelyn and Josh, Please feel free to reopen this one if bug 1214148 cannot be fixed or this bug is not a duplicate of bug 1214148. Thanks!