1199985 - [TV 2.5][Browser] Failed to play a video on Youtube or CNN

Status: RESOLVED DUPLICATE of bug 1214148

(Firefox OS Graveyard :: AudioChannel, defect, P1)

Description

[Cynthia Tang [:cynthiatang]]

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

Comment 1

[Cynthia Tang [:cynthiatang]]

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

Comment 3

[Josh Cheng [:josh]]

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

Comment 4

[Cynthia Tang [:cynthiatang]]

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

Comment 5

[Blake Wu [:bwu][:blakewu]]

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

Comment 6

[Cynthia Tang [:cynthiatang]]

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?

Comment 7

[Cynthia Tang [:cynthiatang]]

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

Comment 8

[Kilik Kuo [:kikuo] (inactive)]

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

Comment 9

[James Cheng[:JamesCheng]]

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

Comment 10

[James Cheng[:JamesCheng]]

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.

Comment 11

[James Cheng[:JamesCheng]]

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.

Comment 12

[James Cheng[:JamesCheng]]

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.

Comment 13

[Evelyn Hung]

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!

Comment 14

[Evelyn Hung]

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.

Comment 15

[Blake Wu [:bwu][:blakewu]]

(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!