891720 - [Youtube][Call] When Playing the Youtube in landscape, Youtube is paused late after incoming call

Status: RESOLVED WONTFIX

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

Description

[leo.bugzilla.gecko]

1. Title : [VOICE CALL] Sound error when recieving call while landscape streaming
2. Precondition : 3G or WIFI is too slow.
3. Tester's Action : 
                1) Open Youtube app and start playing a video in landscape mode
                2) While streaming in landsacp mode recieve a calll check the states
4. Detailed Symptom (ENG.) : The YT from stream is paused late.

Gaia : 0d5a9a7577f16b6a72a982148c6f509ee1714ea2
Gecko : 499c1f8ea7ad0cdaa7086214278e2944b8a2ea33

I reviewed and tested with patch in Bug 890776. But It is reproduced. 
Youtube keep to be played for a second even though activity(incomming call) is changed.
I think It appears to be the cause of the landscape screen.

Comment 1

[Seil Park]

Attachment: Issue capture.

Comment 2

[leo.bugzilla.gecko]

When the network state is bad, It is played more for the several seconds after incomming call.

Comment 3

[John Hu [:johnhu][:johu][:醬糊小弟]]

Leo, 

Since bug 887454 is landed, the source in v1-train uses browser native video element to play video. It is nice to do the test again because the implementation is totally different.

Comment 4

[leo.bugzilla.gecko]

Is bug 887454 for User Agent while youtube streaming?

I think you picked wrong number.
Could you please let me know one more time?

Comment 5

[Jason Smith [:jsmith]]

(In reply to leo.bugzilla.gecko from comment #4)
> Is bug 887454 for User Agent while youtube streaming?
> 
> I think you picked wrong number.
> Could you please let me know one more time?

Nope, that's the right bug number. We removed the user agent override for YouTube, so media content will render inline in the YouTube site/app now. So the STR in this bug won't happen anymore, which is why this is being asked to be retested.

Comment 6

[John Hu [:johnhu][:johu][:醬糊小弟]]

Thanks Jason.

Please retest it, Leo. Thanks.

Comment 7

[Wayne Chang [:wchang]]

ni? leo

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

First of all, callscreen is not an activity. It's attentionscreen.

Second this smells like an audio competing issue, totally irrelevant to orientation change. Why do you think so?

Comment 9

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

>>MT call
07-17 19:28:28.666 E/AudioPolicyManager(  117): setPhoneState() state 1
>>Ringtone ring..
07-17 19:28:30.758 I/( 1917): StartPlaying 1
07-17 19:28:30.978 I/( 1917): CanPlayChanged........1 <--ringtone media element
...

7-17 19:28:32.280 I/( 1896): nsHTMLMediaElement::CanPlayChanged........0 <---video media element paused.

Need to find why it cause this callback delay.

Comment 10

[Seil Park]

(In reply to Wayne Chang [:wchang] from comment #7)
> ni? leo
it may has the risk of fixing the issue.
If it dosen`t have the risk. please change the leo+.

Comment 11

[Alex Keybl [:akeybl]]

At this point we don't have a fix in hand, therefore the risk is unknown. Let's devote resources to more critical blockers.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Moved to general since this is an audio-competing issue.

Comment 13

[Dominic Kuo [:dkuo]]

[UX_TRIAGED]

Although this is also related to the audio competing issue(because the visibility is coupling with the audio channel now), but if the ongoing window management about the attention window(Bug 927862) fixed, that bug should fix this issue as well, because the visibility can be correctly set. So let's first set the dependency to it and trace it.

Comment 14

[BMO Automation]

Firefox OS is not being worked on