910340 - When screen is switched off, visibilitychange is not firing when audio is playing

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: AudioChannel, defect)

Description

[:Harald Kirschner :digitarald]

Attachment: audio-stop.zip

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).

Comment 1

[:Harald Kirschner :digitarald]

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.

Comment 2

[Jason Smith [:jsmith]]

Is this bug present on 1.01?

Comment 3

[:Harald Kirschner :digitarald]

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.

Comment 4

[Jason Smith [:jsmith]]

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

Comment 5

[Martin Best (:mbest)]

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.

Comment 6

[Martin Best (:mbest)]

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.

Comment 7

[:Harald Kirschner :digitarald]

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.

Comment 8

[Preeti Raghunath(:Preeti)]

Can this bug be closed? per Comment 7.

Comment 9

[:Harald Kirschner :digitarald]

(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!

Comment 10

[Preeti Raghunath(:Preeti)]

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.

Comment 11

[:Harald Kirschner :digitarald]

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.

Comment 12

[Andrea Marchesini [:baku]]

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?

Comment 13

[:Harald Kirschner :digitarald]

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.

Comment 14

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

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

Comment 15

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

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.

Comment 16

[Preeti Raghunath(:Preeti)]

Based on comment 13 a work around is available for 1.1

Comment 17

[mbishop]

Attachment: Demonstrates bug even with workaround

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?

Comment 18

[:Harald Kirschner :digitarald]

(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

Comment 19

[:Harald Kirschner :digitarald]

Making sure mbishop sees this.

Comment 20

[mbishop]

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!

Comment 21

[Bobby Chien]

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

Comment 22

[Andrea Marchesini [:baku]]

(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.

Comment 23

[Bobby Chien]

(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.

Comment 24

[Florian Bender]

(In reply to Bobby Chien [:bchien] from comment #23)
> > ... but the visibility state should change. ...
> agree.

Where will this happen? This bug?