User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; aff-kingsoft-ciba; Zune 4.7) Steps to reproduce: 1.open browser to surf youtube 2.open a video and play in full screen 3.turn off the screen Actual results: in step 3,the video keep playing(judge from the sound) Expected results: the video should pause after turning off the screen

I think this is ready to be worked on, and is likely something that has already been looked into at the platform level, I dont know off the top of my head how it will be fixed though, needinfoing brad and sicking

(In reply to Dale Harvey (:daleharvey) from comment #1) > I think this is ready to be worked on, and is likely something that has > already been looked into at the platform level, I dont know off the top of > my head how it will be fixed though, needinfoing brad and sicking Before we talk implementation here, what does Android do as a point of comparison when a YouTube video is playing and the screen goes off?

Ok, so after disabling my youtube app from my Android device to force in-browser playing, I have realized this is broken. I am filing a bug. Saying that, I confirmed with Ian Barlow (UX) that when you turn off the screen, the video should stop playing. This is also the same behaviour exhibited by the youtube app on Android as well. (Audio follows the same behaviour, although we are discussing the more plausible use-case of someone wanting to listen to audio with the screen off - but that can be discussed in another bug.)

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/55431776

Followup question - Why is this a Gaia::Browser specific bug? Why wouldn't this be implemented in the System app?

Should be general.

Hi all, There is a hack on system app which will not send visibility change event to top app when audio with normal channel is on going. In this case the youtube is playing under normal channel so it will not know that it is on background when pressing power key to sleep. Bug 894249 introduced to split normal for audio or video so based on it we can send "visible-audio-channel-changed" with a specific data so system app can ignore this hack when audio is played by video. Finally audio competing policy will ask video to pause. Is this a way to fix bug?

discussion of what the "right" android behavior should be is happening in bug 827756

This is by design. Since we want to support websites acting as music players, and we want music players to keep playing even when the user turns off the screen, and such websites generally won't know that FirefoxOS even exists, much less be willing to use FirefoxOS specific APIs to keep on audio when the screen is turned off, we ended up with the current solution. The current solution is that we let the front-most app keep playing audio, if it's currently playing audio, when the screen is turned off. If the user wants to turn off the audio, the user has to first exit the app by pressing the home button, before turning off the screen. We have debated adding UI which enables the user to select that a particular website or app should keep playing when the screen is turned off. And that way we could change the default so that audio is turned off when the screen is turned off. But we need someone from the UX team to design such a UI. The platform API support should already be there on mozilla-central.

Jonas - why would we want to implement a different UX behaviour design over what the standalone app (and fennec) does? Was that a conscious decision based on feedback? An audio channel would serve as a better argument than video and one I could more easily accept. But for video, there are countless scenarios where people want to kill the sound quickly instead of having to consciously go to the screen to do it (like if someone walks in on you, you click on a video by accident and you're in a doctor's office, etc).

Because most of the content that people are going to be using on FirefoxOS devices in the near future is content that was not written for FirefoxOS. I.e. it is random webpages that people picked up from e.me or by simply browsing the web. I guess we could make a distinction between videos and audio-only content. However a lot of people do use YouTube as a music player, so I'm not actually sure that that's the right thing to do in all cases. Rather than trying to apply even more heuristics I'd prefer to avoid the clippy-problem and spend time creating UI which enables the user to control which apps/websites should keep playing in the background and which ones shouldn't. The current behavior was heavily pushed for by TEF.

HI Jonas, Do you consider the solution from Comment 7 for V1.1? > The platform API support should already be there on mozilla-central. If you mean bug 853101 then it is not landed yet.

Hi,i wonder if you think this issue is a problem and should be fixed?

Karen/Jonas, can we agree on if this would be changed from it's current behaviour?

(In reply to Wayne Chang [:wchang] from comment #15) > Karen/Jonas, can we agree on if this would be changed from it's current > behaviour? Even if we decide to change behavior here, this isn't a blocker for HD release. This current behavior is what is shipping on 1.01 & 1.1 target devices. HD blockers are supposed to only focus on HD-specific issues.

I'm opposed to changing anything here until we get a spec from UX about a comprehensive audio policy. We've been tweaking the current audio policies enough since last time UX was involved and things have very complicated over time (did you know that we now have 8 audio channels and 4 different volumes?) We have lots of outstanding issues as well, such as this one, and it would be good to have a comprehensive go-over and get everyone on the same page. The problem described in this bug was shipped in v1.0, and as far as I know we've not seen a lot of complaints, so I don't see any reason to block v1.1 or v1.1hd on it.

The UX involved in audio channel design is no longer on any audio issues. I forget who is in charge of that right now. (In reply to Jonas Sicking (:sicking) (vacation until 9/9. In norway until 9/16) from comment #17) > The problem described in this bug was shipped in v1.0, and as far as I know > we've not seen a lot of complaints, so I don't see any reason to block v1.1 > or v1.1hd on it. This is not totally true. Our v1.0.1 device doesn't change the UA string of youtube. So as it runs in video app's inline activities, it would stop playing when screen is off. This is a regression, but I don't think this blocks release either.

My feeling is that we won't have time to get an agreed and comprehensive UX spec for 1.2 for this (including any distinction between audio and video and a good look at how this behaviour is implemented across other devices). We do have some proof points stated, but I agree with Jonas - we need a comprehensive look at all of these behaviours and lock down an appropriate spec. I'll ask SUMO to dig for any insights from users in the meantime, but I don't believe this is a blocker for 1.2 either.

(In reply to Jason Smith [:jsmith] from comment #16) > (In reply to Wayne Chang [:wchang] from comment #15) > > Karen/Jonas, can we agree on if this would be changed from it's current > > behaviour? > > Even if we decide to change behavior here, this isn't a blocker for HD > release. This current behavior is what is shipping on 1.01 & 1.1 target > devices. HD blockers are supposed to only focus on HD-specific issues. Agree. Sorry should have made it clear that my comment 15 meant a resolution for v1.2 so I can get back to partner. Not HD blocking here as this is consistent behaviour on v1.1 leo.

(In reply to lecky from comment #14) > Hi,i wonder if you think this issue is a problem and should be fixed? Lecky, For your information, comment 19 states this wont be a blocker for v1.2 either.

(In reply to Karen Rudnitski [:kar] from comment #19) > My feeling is that we won't have time to get an agreed and comprehensive UX > spec for 1.2 for this (including any distinction between audio and video and > a good look at how this behaviour is implemented across other devices). We > do have some proof points stated, but I agree with Jonas - we need a > comprehensive look at all of these behaviours and lock down an appropriate > spec. > > I'll ask SUMO to dig for any insights from users in the meantime, but I > don't believe this is a blocker for 1.2 either. This also occurs for 1.3, should it be a blocker for that?