When the audio tag of Music app is interrupted by the other audio channel, Music app should handle mozinterruptbegin/mozinterruptend to do some UI work. Like Music app should disable all the play controls for playing or pausing audio, that will prevent audio tag from entering wrong state to cause gecko problem. This should happen after gecko really "pause" the audio tag. I think currently gecko just mute the content channel which Music is using.

This should be a blocking+ work. See discussion in bug 796628.

:dkuo what's the ETA for this? it's blocking of the major audio issues.

Why is this blocking? The music is already getting silenced. The only work remaining here is that the UI should gray out various buttons while the audio is silenced. But it doesn't seem very important to do so since the user will unlikely be in the music app when the audio gets silenced. I.e. if the alarm goes off, we'll switch to displaying the alarm app, and so whether the UI in the music app renders disabled controls or not is undetectable to the user. Likewise, if there's an incoming phone call, we'll switch to the telephony app. And so the music app UI won't be visible to the user. I do agree that we should fix this bug. I just don't think it's a basecamp-blocker.

It was marked as blocking 796628, which is a partner blocker. If that's not the case, we can unblock it.

(In reply to Faramarz (:faramarz) from comment #2) > :dkuo what's the ETA for this? it's blocking of the major audio issues. After gecko really pause the audio when mozAudioChannel changes, I guess the audio element of Music will receive events like: mozinterruptbegin > pause > play > mozinterruptend, so Music app can just gray out the various buttons (like Jonas said) when mozinterruptbegin, and revert buttons after mozinterruptend. It might takes me 1-2 days to fix this (patch + review).

BB+, P3 - bug 815569 blocks and this bug is a follow-up of bug 815569

This does not block bug 796628. Bug 796628 is now fixed.

I would say that there are two parts for this bug. 1. Disable "Play", "Previous" and "Next" buttons when mozAudioChannel changes. (depends on mozinterruptbegin/mozinterruptend events, which we already have!) 2. Reflect UI when audio pauses and resumes. (depends on pause and play events which we don't have yet) I think we should at least do part 1 because it can prevent audio element from entering wrong state, which maybe caused by users tapping "Play", "Previous" and "Next" after mozAudioChannel changes. I know this is a rare condition that after an user answered his call, he still switch back to Music to so some UI controls, but disable the buttons doesn't harm and protects the audio element. (I have done some experiments, if we pause audio in Gaia after mozinterruptbegin fired, mozinterruptend does not fire after a connected call ends) And I saw Bug 815569 became a blocking-basecamp+ bug, so it means gecko will really pause and resume audio when mozAudioChannel changes? if so, I would consider part 2 is a better-to-have since we already done part 1, why not also do part 2 ^^

(In reply to Dominic Kuo [:dkuo] from comment #8) > I would say that there are two parts for this bug. > > 1. Disable "Play", "Previous" and "Next" buttons when mozAudioChannel > changes. > (depends on mozinterruptbegin/mozinterruptend events, which we already have!) > > 2. Reflect UI when audio pauses and resumes. > (depends on pause and play events which we don't have yet) I'm not really sure what you mean here. mozAudioChannel only "changes" when the app changes it. It's not something that the platform automatically changes for you. The mozinterruptbegin/mozinterruptend events are fired when the platform automatically pauses the audio element (or mutes it, until bug 815569 is fixed). So the only thing that needs to be done here (once bug 815569 is fixed), is to gray out the play/previous/next buttons in response to the mozinterruptbegin/mozinterruptend events. Or am I misunderstanding something?

(In reply to Jonas Sicking (:sicking) from comment #9) > I'm not really sure what you mean here. mozAudioChannel only "changes" when > the app changes it. It's not something that the platform automatically > changes for you. > > The mozinterruptbegin/mozinterruptend events are fired when the platform > automatically pauses the audio element (or mutes it, until bug 815569 is > fixed). That's what I am talking about here, if the audio element is "paused" by platform, the icon of the play button should also reflect what's really happening, that means the icon of play button should be changed from || to ► , just like an user pauses the music by tapping the play button. So Part 2 is listen to "pause" and "play" events to change the icon states of play button. > So the only thing that needs to be done here (once bug 815569 is fixed), is > to gray out the play/previous/next buttons in response to the > mozinterruptbegin/mozinterruptend events. Yes, I agree with you, so that's part 1. > Or am I misunderstanding something? I attached one image to explain Part 1 and 2, there four states for play/previous/next buttons: (1) and (2) are before mozinterruptbegin, like normal playing and pausing. (3) is after mozinterruptbegin, note that the buttons are gray out, the audio is still playing with platform mute only. (4) once platform both mute and pause the audio after mozinterruptbegin, the play button is not just gray out but also changed icon from || to ►.

The player, should gray out the controls, and (visually) the control should change to the play button. Having a grayed out pause button would imply that audio is actually playing in the background but is inaudible. Once the mozaudiochannel changes back to music, the play button would change the pause button and the audio would resume playing without user input.

Note that after landing bug 828200, the foreground app can play all of it audio no matter what channel it is.

Does anyone on the UX team know what the deal with this bug is? I'm thinking it's probably irrelevant now, but I could be wrong.

From UX triage: This bug needs to be re-tested to see if it's still valid. Ping us again if it requires more UX input. Thanks for pinging the UX team.

Using Aries Master and Flame 2.5 I am seeing that if a song is being played and then an Alarm is triggered during that that the song will continue playing (with no audio from the song, just the audio from the larm). Additionally the buttons are not greyed out. Environmental Variables: Device: Aries 2.5 BuildID: 20151029161147 Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0 Gecko: ac68828c5e3e2ac4fabcfde859440a749e0f5fbf Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 45.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0 Environmental Variables: Device: Flame 2.5 Kk Fullflash (512mb) BuildID: 20151029045227 Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0 Gecko: acb3f4ac5424181d3d4d73283668162137918cf1 Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a Version: 45.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Jim I'm not quite sure what the expected here is since comment 12 and comment 13 seem pretty contradictory to me. What are your thoughts with the results from comment 16?

From the UX spec[1], the behavior should be to pause the music while the alarm plays, but I'm not sure if that's the behavior UX actually wants here. [1] https://bug1068219.bmoattachments.org/attachment.cgi?id=8579177

The correct behaviour is outlined in the spec Jim references. The music is paused while the alarm plays and then the music resumes when the alarm stops. Thanks!

Firefox OS is not being worked on