User-Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 STR: play an mp3 file in the Browser app and switch off the display. The audio immediately stops. It should instead continue playing. The Music Player app gets this right.

I think it is not a bug. It just follows the UI spec[1]. In UI spec[1], it says the audio channel of `normal` type is paused when inactive/screen off, resumes when active again. And I also confirmed this with the UX designer of audio channel management. [1]: https://bug1068219.bmoattachments.org/attachment.cgi?id=8579177

Hi > [1]: https://bug1068219.bmoattachments.org/attachment.cgi?id=8579177 From the spec you cited: "Each app can decide to continue playback or to pause when inactive/screen off, ..." That leaves at least the possibility of continuing to play. I often listen to podcasts directly in the browser. The current behavior completely breaks this use case. Before this gets dismissed as WONTFIX, I'd rather like to see if there are ways to support my use case. Patryk, could we have a setting to override the current behavior, so that the Browser app continues playing while the screen is locked and off?

Agree with you Thomas since we don't have a decided podcast subscription app people will likely play podcasts via the browser. I have a similar annoyance with the youtube app not being able to be played when the phone is locked (not all videos are actually worth watching especially when its a music playlist or a discussion). So yes we should add overwrites for this.

Hi, Here are some additional information about my use case. Downloading audio files before listening to them is annoying. So I usually let them play directly on the web page and sometimes read the comments/discussion en passant. When I'm done reading, the display turns off after a while. I don't know much about our overall UX concepts, but for what I do a simple switch in the Settings app would be fine. For example, Settings::Sound could have a toggle button 'Keep playing audio while device is locked', and general-purpose apps would act accordingly.

Hi Tori, How do you think about this?

I can reproduce this on the latest Aries and Flame master builds Audio will stop playing when the device falls asleep or locked. Device: Flame 2.5 (Full Flash)(KK)(319mb) Build ID: 20150812030210 Gaia: c7875bbc8b32e7b95cc55c9690b03b140905d84d Gecko: d4f3a8a75577e4af2914a4e899ca2e724f9715c4 Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 43.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 Device: Aries 2.5 (Full Flash)(KK)(319mb) Build ID: 20150812135535 Gaia: 6fef72357971934c8774578044ea7a442be3a75d Gecko: b7efed3a2640fba681d48846c3b2ab80474c6f77 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 43.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 This does not occur on the Flame 2.2 Audio continues to play after the device has been locked or falls asleep. Device: Flame 2.2 (Full Flash)(KK)(319mb Build ID: 20150812032504 Gaia: 102f1299e9eafe3760e1deb44d556b5c4f36b5af Gecko: 9295034c0ee3 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Cause: The changes for Bug 1113086 seem to have caused this issue. Mozilla-inbound Regression Window Last Working Environmental Variables: Device: Flame 2.5 BuildID: 20150710163851 Gaia: e4b63559eba364892867eb381c3002d6518e5d6a Gecko: 07bcf36f5ab2 Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 First Broken Environmental Variables: Device: Flame 2.5 BuildID: 20150710170452 Gaia: e4b63559eba364892867eb381c3002d6518e5d6a Gecko: 675ea719b91c Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Last Working gaia / First Broken gecko - Issue DOES occur Gaia: e4b63559eba364892867eb381c3002d6518e5d6a Gecko: 675ea719b91c First Broken gaia / Last Working gecko - Issue does NOT occur Gaia: e4b63559eba364892867eb381c3002d6518e5d6a Gecko: 07bcf36f5ab2 Gaia Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=07bcf36f5ab2&tochange=675ea719b91c

Andrea, can you take a look at this please? This might have been caused by the work done for bug 1113086.

It's the known issue that web content can't play audio in background, see bug1084464 for more info. We can done it before is because some workaround and them have been removed by bug1113086.

UX have a proposal in another similar thread: https://bugzilla.mozilla.org/show_bug.cgi?id=1191730 Sometimes users leave the app/lock the screen because they really want to stop consuming the content(video/audio); sometimes users want to keep audio as background music. We can enable background music, but for users who want to entirely close the website, it can be annoying. But if we let them close music easily, I think it is not a big issue. Proposal: Keep playing music in background mode, provide info and quick control(pause/end) on the lock screen and status bar. It can provide convenience and give the choices back to users.

[Blocking Requested - why for this release]: Per comment 3, I think it should be a blocker. nominating to start a discussion.

Blocking for 2.5 as all browser based music Eg: Pandora etc cannot be used. Setting a P3 priority

Hi Alastor, Does gecko stop the music in Browser app after turns off screen? The Audio Channel Service module in gaia didn't receive `audiochannelstatechanged` event after turned off screen. So Audio Channel Service module didn't do anything for the music. And it means that the music is not stopped by Audio Channel Service. For Comment 9, it looks like a gecko issue. How do you think? Thanks.

Hi, Evan, I have checked code flow, the The music is stopped by Gaia's AudioChannelController. The AudioChannelController would mute the music when the screen is off. The "audiochannelstatechanged" event would be send when (1) The FIRST specific channel type audio of this window starts playing (2) The LAST specific channel type audio of this window stops playing

After offline discussion with Evan, this issue would use the Gaia solution.

Hi Alastor, Comment 16 is the test patch to fix Bug 1190434. You can apply it and continue to fix Bug 1214245. I'll add test later, and send review request to you. Thanks.

Sorry, not to fix Bug 1214245, to fix Bug 1212974.

Comment on attachment 8673451 [details] [gaia] evanxd:bug-1190434 > mozilla-b2g:master Hi Alastor, Could you review the patch? Thanks.

Hi Tori, In the email, looks like we need to do more discussion about the UX design for the bug. And we need the UX spec here to fix this bug. Thanks.

ni Mark for update.

This is a regression bug (it works for previous version). UX will discuss and open a new bug to describe our proposal for this bug. Thanks.

If playing stops when the audio turns off, and that's a new design, that's fine. Having said that it should start to play again once the screen turns on. Bug 1212974 is NOT a duplicate of this bug as we're having issues playing the audio/video once returning.

oops. I shouldn't say that's fine so quickly. There are cases when you want the audio to continue playing. One of them is to turn the music app on and then play with the display off to save battery power. Even youtube and a few others would be like that and this could potentially break alarm from sounding as well when the display is off. This also does need a revisit in use cases.

A P1 bug, since it's the duplicate of a P1 bug.

Hi Naoki, Yes, Bug 1212974 is not a duplicate of this bug. But Bug cannot be reproduced in the latest build[1]. For UX design, Mark said(Comment 23) he will create a new bug for it. [1]: https://bugzil.la/1212974#c21

Treeherder is good[1], let's land the code. [1]: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=25085bf322ea5ece64c53ea44c3b548085724403

master: https://github.com/mozilla-b2g/gaia/commit/ccbd181bc816ab3a6a6290bc3b80d77d4919d79d

Thank you for fixing this bug! Really appreciated.

Thanks. this bug isn't in today's build; my primary use case for music app is to play with the lockscreen on ... ie I would work out, jog, walk etc. and hit the sleep button. We will wait until next week to release OTA.

oops. Sorry. I meant this bug's patch is not in today's build.

Evan, with this patch, a normal audio channel will be played in background? what's the background mean? does it mean the phone is currently screen off(or on lockscreen) or there is an app in the foreground?

Evan, I understand this is a late spec change so please also update https://wiki.mozilla.org/WebAPI/AudioChannels accordingly.

Specifically, https://wiki.mozilla.org/WebAPI/AudioChannels#Audio_Competing_Policy

This issue has been verified as fixed on the latest Aries and Flame master Audio continues to stream after manually locking the device or after allowing the device to fall asleep. Device: Aries 2.5 Build ID: 20151019104907 Gaia: f75bd584aca0a751a5bed115800250faa8412927 Gecko: d3e87bb40753327550143ba8ac8ee27b300cd4a9 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 44.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Device: Flame 2.5 (Full Flash)(KK)(319mb) Build ID: 20151019030208 Gaia: f75bd584aca0a751a5bed115800250faa8412927 Gecko: 1a157155a4fe0074b3d03b54fe9e466472c2cd56 Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 44.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

(In reply to Evelyn Hung [:evelyn] from comment #34) > Evan, with this patch, a normal audio channel will be played in background? Yes. > what's the background mean? does it mean the phone is currently screen > off(or on lockscreen) or there is an app in the foreground? We can get top-most window from `Service.query('getTopMostWindow')`. If an app's window is not top-most window, it mean that the app's window is in background. For example, screen off, on lockscreen, another app in foreground, the situations means the app's window is in background.

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #35) > Evan, I understand this is a late spec change so please also update > https://wiki.mozilla.org/WebAPI/AudioChannels accordingly. Updated, thanks.