Expected: When the phone is switched off, an app should be able to stop all audio playing and resume when it comes visible again. Actual: The visibilitychange event when switching off the screen does not fire when audio is playing. Bug: When the device screen is switched off, a visibilitychange event should fire. This works only when audio is not playing. Visibilitychange events that get fired when the app goes into the background work as expected. All games with sound that reacts to visibilitychange to pause/resume are affected. Verified on ZTE Open and Unagi with b2g18 Nightly (20130828041203).

Blocker for a few games without workaround. The app can't know about the screen state and as the audio keeps playing the app is incorrectly blamed.

Is this bug present on 1.01?

Test case available as website as it does not need to be a packaged app, it is also reproducible in the browser: http://git.io/b910340 Same bug happens on 1.0.1, tested on Unagi.

Can't block on this then if it reproduces on 1.01. We can slot this in for a future release.

I wanted to add that higher profile games will simply not be willing to ship on the devices as long as this bug hangs around.

A work around is out best bet, but if there isn't one, then we really need to figure out how to get this into a shipping build asap.

No work-around so far. Onblur fires too late, only after the screen is switched on again and the user interacts with the lockscreen. I will open another bug about this behavior.

Can this bug be closed? per Comment 7.

(In reply to Preeti Raghunath(:Preeti) from comment #8) > Can this bug be closed? per Comment 7. I don't understand. The bug is severe, affects priority partner apps. Comment 7 just clarifies that there is so far *no* workaround. We need this in leo!

I asked if the bug can be closed based on the comment, "I will open another bug about this behavior". If we are retaining this bug we're good.

Pardon the confusion. The bug I still need to file is about the aforementioned unpredictable behavior of onblur which would have offered a work-around.

The reason why we have this behaviour is that a partner wants to let the browser to play if it's in foreground and the device is locked. The browser, as any 'standard' application uses 'normal' as AudioChannelType. So we wrote an horrible hack that doesn't send the visibility change event when an app is playing audio, it's in foreground and the device is locked. What you are asking is to remove this hack. Sounds reasonable, but then we break the other feature. Have you tried to use 'content' as audioChannelType? You need to have the right permissions in the manifest of your app. Alive, can you give a feedback about this?

We have a workaround! I added mozAudioChannelType to the test case and it works. If an app wants to continue to play audio when the user switches the device off, isn't that what audio channels are for? needinfo on :alive to get more feedback on the bug.

Yes, normal channel keeps playing and doesn't get visibilitychange event if it's active + playing right before screen is off. This is intentional.

FYI we're discussing to let normal channel playing at background by default and let the app stops itself when visibility is hidden. See bug 91123 [Bug 911238] [AudioChannel] Consider to let normal channel play in the background.

Based on comment 13 a work around is available for 1.1

Hi all, I've attached another test-case that uses the "content" channel but the beg remains. Is the test case bad or does the workaround not work? If the test case is bad, can you upload one that shows the workaround?

(In reply to mbishop from comment #17) > Hi all, I've attached another test-case that uses the "content" channel but > the beg remains. Is the test case bad or does the workaround not work? If > the test case is bad, can you upload one that shows the workaround? I am still going through emails after being OOO and haven't tested this: The correct HTML attribute should be "mozaudiochannel" [1], not "mozAudioChannelType" (which is the property). [1]: http://mxr.mozilla.org/mozilla-central/source/content/html/content/test/test_mozaudiochannel.html?force=1#13

Making sure mbishop sees this.

Thank you for putting me in the loop and providing the corrections. With an updated test case (and updating our code), the workaround appears to work. Thank you!

Continue playing audio is right scenario as mobile phone behavior. I think we don't need to force fixing the visibilityChange bug.

(In reply to Bobby Chien [:bchien] from comment #21) > Continue playing audio is right scenario as mobile phone behavior. I think > we don't need to force fixing the visibilityChange bug. Correct. This behavior is not going to change, but the visibility state should change. Currently we have an hack and soon or late we must remove it.

(In reply to Andrea Marchesini (:baku) from comment #22) > (In reply to Bobby Chien [:bchien] from comment #21) > > Continue playing audio is right scenario as mobile phone behavior. I think > > we don't need to force fixing the visibilityChange bug. > > Correct. This behavior is not going to change, but the visibility state > should change. > Currently we have an hack and soon or late we must remove it. agree.

(In reply to Bobby Chien [:bchien] from comment #23) > > ... but the visibility state should change. ... > agree. Where will this happen? This bug?