833211 - Video playback continues when display is turned off

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Video, defect)

Description

[Michael Vines [:m1] [:evilmachines]]

Test Steps:
1. Insert wired headset to the phone.
2. Enable cellular data connection in phone.
3. Browse and play a video from YouTube.
4. While playing video from YouTube, press the power key slowly.

Expected result.
Video should stop when display is off.

Actual:
Streaming is going on in background and able to hear the audio, Even after coming out of the suspended state also, the video is in updated state.


Feedback from test folks is that this is not desirable behavior and inconsistent with other platforms.  Expectation is that the user is turning off the display for power-saving reasons, so video continuing with the display off inhibits suspend.

Comment 1

[Marco Chen [:mchen]]

Hi Alive,

I found that youtube video will be played by "video/js/view.js" in Browser process. And the mozAudioChannelType is set to 'content' so it is allowed to play in the background.

  Q1: Since video doesn't be allowed to play in the background, do we need to modify channel to normal not content in view.js and video.js?

  Q2: The visibility of browser app in lock screen is still true. Is anything wrong here?

Thanks.

Comment 2

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

This is a gaia bug. Video from youtube is using web activity, which doesn't deal with visibilitychange event.

I wonder inline activity in system app doesn't setVisible either.

Comment 3

[Michael Vines [:m1] [:evilmachines]]

(our test folks feel this is a P1 for tef, don't shoot the messenger!)

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This seems to be the desired behavior per product, v. bug 828283.  (Although I think unexpected in our current implementation.)

Comment 5

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

(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> This seems to be the desired behavior per product, v. bug 828283.  (Although
> I think unexpected in our current implementation.)

I don't think these two bugs are the same thing.

bug 828283 is talking about the default behavior of any app which doesn't have background-playing permission.
This bug is talking about playing video from youtube via our video viewing activity. This should be corrected without any decision in bug 828283. Although I need to pollute the window manager in order to fix this bug...

Comment 6

[Marco Chen [:mchen]]

Hi Alive,

After reading bug 828283, it tried to achieve that "any foreground app playing with media element can continue to play even user pressing power key to suspend mode". The rough idea there is let foreground app with playing state doesn't get visibility change during lock screen.

Once that patch is landed, in the test steps of this bug the youtube player doesn't know it is falling to background and covered by lock screen (even the screen now is off). So it never stop to play.

It seems that the bug here and 828283 is conflict.

Comment 7

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

OK, I am fine with that. Thanks for clarification.

(In reply to Marco Chen [:mchen] from comment #6)
> Hi Alive,
> 
> After reading bug 828283, it tried to achieve that "any foreground app
> playing with media element can continue to play even user pressing power key
> to suspend mode". The rough idea there is let foreground app with playing
> state doesn't get visibility change during lock screen.
> 
> Once that patch is landed, in the test steps of this bug the youtube player
> doesn't know it is falling to background and covered by lock screen (even
> the screen now is off). So it never stop to play.
> 
> It seems that the bug here and 828283 is conflict.

Comment 8

[Marco Chen [:mchen]]

But the problem now is that the user behavior here is conflict with bug 828283.

Hi Michael,
Could you accept the behavior from bug 828283 or could you give comment into that bug?
Thanks.

Comment 9

[Michael Vines [:m1] [:evilmachines]]

Feedback from our test folks is that playing audio with the display off (bug 828283) is consistent with other platforms.  

The behavior raised in this bug however is subjective and based solely on experience with other platforms, and has nothing to do with certification.   So if the risk of making this change is too high for v1.0.0 then please do push back.

Comment 10

[Alex Keybl [:akeybl]]

This is as designed and is avoidable by the user (or could even be considered a feature), so no need to block/track.