Please report any other irregularities here.
52 bytes, text/plain
STR: 1. Open Video Player and play any video clip. 2. Rotate the device to landscape mode.(Video decode will start playing in landscape mode) 3. Now Press Home Key. Issue: Video clip Audio keeps playing in background. Expected: video decode should pause and Video clip Audio should not be heard while we are on home screen. Build Info: v1.3 gaia: 01e9da49be2cc4bc134eeefc434740d572ec2246 gecko: 252332f9d779541d82b87b9e17b57a4d5a978443
This is invalid - the video app has it's sound handled by a content audio channel, which allows sound to be played back in the app while it's in the background.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
Jason, is this new feature/behavior? Don't see it happen in v1.2. Also, why does it happen in landscape mode only?
(In reply to Inder from comment #2) > Jason, is this new feature/behavior? Don't see it happen in v1.2. Also, why > does it happen in landscape mode only? This behavior has been the same since 1.01 - sound from the video app should play while the app is in the background. If the opposite behavior is seen on 1.2, then the opposite behavior is a bug on 1.2. Not sure why the right behavior happens in landscape, but not portrait. I would open a new bug for this on the incorrect behavior seen in portrait mode.
> sound from the video app should play while the app is in the background. Jason -- what happens to the video decode then? Looks like that's also happening in the background. I am not yet convinced if the correct behavior is to keep video playback happening in background. It makes sense for Music app but Video app should stop decode when moved to background. Let's keep this bug opened till we either fix this issue or open follow up bugs to fix the behavior on all other branches. Otherwise we don't have a way to track it.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to Inder from comment #4) > > sound from the video app should play while the app is in the background. > > Jason -- what happens to the video decode then? Looks like that's also > happening in the background. I am not yet convinced if the correct behavior > is to keep video playback happening in background. It makes sense for Music > app but Video app should stop decode when moved to background. I don't think so. The main reason why you would play videos in the background is similar to why music can play in the background - to be able to keep hearing the audio while you go do something else. There's a huge use case of videos that exist where their value heavily comes from their audio. For example, take a recorded radio show that happened to only come in video format. Anyways - I don't think it makes sense to switch around behavior that has been deemed a partner requirement (different partner) since 1.01. As you can see from the manifest values per each branch below, this behavior has existed since 1.01: - Master - https://github.com/mozilla-b2g/gaia/blob/master/apps/video/manifest.webapp#L17 - 1.2 - https://github.com/mozilla-b2g/gaia/blob/master/apps/video/manifest.webapp#L17 - 1.1 - https://github.com/mozilla-b2g/gaia/blob/master/apps/video/manifest.webapp#L17 - 1.01 - https://github.com/mozilla-b2g/gaia/blob/v1.0.1/apps/video/manifest.webapp#L16 This same code snippet for declaring permission for use of the content audio channel also exists in the music app. The audio channel documentation also explicitly calls out the video app as following the content audio channel: https://wiki.mozilla.org/WebAPI/AudioChannels The music app also has the same audio channel as videos. Therefore, I fail to see why the behavior proposed in this bug is valid. We've followed this behavior since 1.01 & I don't see a strong reason to change it. We would be throwing out a huge array of valid use cases if we changed it.
Thanks Jason for detailed clarification. I guess now we need followup bugs to figure out why this functionality is broken in v1.2 and v1.3. And, though I haven't verified most likely on master branch too. It's weird that it only works in v1.3 and that too in landscape mode only.
(In reply to Inder from comment #6) > Thanks Jason for detailed clarification. > I guess now we need followup bugs to figure out why this functionality is > broken in v1.2 and v1.3. And, though I haven't verified most likely on > master branch too. > It's weird that it only works in v1.3 and that too in landscape mode only. On a 12/19/2013 Master build on Buri, when I hit the home button, the video stops playing. So I guess there's a pretty strong inconsistency here between branches. I'm putting qawanted here to see what the behavior 1.1 is for the video app.
Additional code reference also for this is here: https://github.com/mozilla-b2g/gaia/blob/master/apps/video/js/video.js#L35 Which cites that video is using a content channel.
Wait a second - I'm actually not right here. If you look here: https://github.com/mozilla-b2g/gaia/blob/master/apps/video/js/video.js#L97 That code cites that the video app is intended to pause media when the video app loses visibility. That behavior has been around since 1.01. My guess is that a content audio channel is being used here to handle conflicts with the music app in case the video app starts up with the music app already playing.
Can we double check that this reproduces on a 1.3 buri device? I didn't see this happening on 1.4 recently, so I'm wondering if something was uplifted to already fix this.
This issue does reproduce on the 01/02/14 1.3 build on Buri. The video's audio will continue to play when pressing the Home button while the video is in landscape mode. But when pressing the Home button with the video in portrait mode, the video's audio will stop playing. Environmental Variables: Device: Buri v1.3 MOZ RIL BuildID: 20140102004001 Gaia: 01e9da49be2cc4bc134eeefc434740d572ec2246 Gecko: 61f553e5db49 Version: 28.0a2 Firmware Version: V1.2_US_20131115
This issue started reproducing on the 11/07/13 1.3 build. - Works - Environmental Variables: Device: Buri v1.3 MOZ RIL BuildID: 20131106040203 Gaia: 3b5fe429f2414f2a9d7241b311b399033bb10612 Gecko: 9ba3faa35c96 Version: 28.0a1 Firmware Version: V1.2_US_20131115 - Broken - Environmental Variables: Device: Buri v1.3 MOZ RIL BuildID: 20131107040200 Gaia: 42bbe26a72e030faf07a6fc297f61a3a8ccda25b Gecko: 70de5e24d79b Version: 28.0a1 Firmware Version: V1.2_US_20131115
(In reply to Jason Smith [:jsmith] from comment #9) > > My guess is that a content audio channel is being used here to handle > conflicts with the music app in case the video app starts up with the music > app already playing. If the video uses hw video codec for plabyack and a document is set to hidden state, HTMLMediaElement::NotifyOwnerDocumentActivityChanged() set MediaDecoder to dormant state and video playback stops. http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLMediaElement.cpp#3398
Hi, When pressing the home button during video playing, the video app can receive visibility change event on portrait mode but can't receive event on landscape mode. So it may be related to window management of System app.
I agree. Change the component based on Comment 14.
Component: Gaia::Video → Gaia::System::Window Mgmt
Whiteboard: [CR 593836] → [CR 593836][FT:System-Platform]
Alive, Can you please take a look at the same?
1.3+ as QC needs this issue fixed by 1/10/14.
blocking-b2g: 1.3? → 1.3+
Assignee: nobody → alive
Alive, Any update here? Please provide next steps.
Created attachment 8357659 [details] https://github.com/mozilla-b2g/gaia/pull/15140/files The root cause is in orientationchange/resize case, the getScreenshot call on mozbrowser iframe seems nonreponsive. Add a timer to ensure the getScreenshot of AppWindow give us feedback. This doesn't happen on master/v1.4
Attachment #8357659 - Flags: review?(timdream)
Attachment #8357659 - Flags: review?(timdream) → review+
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=957961 for platform
v1.3 https://github.com/mozilla-b2g/gaia/commit/f79532e643cba364c6531c5dbbc7549c3875bebf Do not uplift to master
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
status-b2g-v1.3: --- → fixed
status-firefox28: --- → fixed
Resolution: --- → FIXED
status-firefox28: fixed → ---
status-b2g-v1.3T: --- → fixed
Target Milestone: --- → 1.3 C2/1.4 S2(17jan)
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.