sync-1 Reporter
	Description • 11 years ago

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171
 Firefox os  v1.1
 Mozilla build ID:20130722070207
 Created an attachment (id=476359)
 Logcat
 
 DEFECT DESCRIPTION:
 The music progress bar still is playing when alarm comes
 
 REPRODUCING PROCEDURES:
 Precondition: plug in the standard headset
 1.Launch Music app -> select a song to play 
 2.Launch Clock app -> set an alarm in one minute, save it
 3.Alarm comes at time -> set alarm reminder to status bar -> then enter music   -> the music progress bar still is playing and it has no sound  -> KO
 
 EXPECTED BEHAVIOUR:
 The music should pause when alarm comes.
 If designed that the music still plays, it should has sound.
 
 ASSOCIATE SPECIFICATION:
 TEST PLAN REFERENCE:
 TOOLS AND PLATFORMS USED:
 USER IMPACT:
 Mid
 REPRODUCING RATE:
 5/5
 For FT PR, Please list reference mobile's behavior:

	sync-1 Reporter
	Comment 1 • 11 years ago

Clone from brother

	iliu@mozilla.com, ianliu.moz@gmail.com
	Comment 3 • 11 years ago

The issue could be no updating status from audio channel. Clock app is not able to handle it for music app.

	Dominic Kuo [:dkuo]
	Comment 4 • 11 years ago

If the progress bar is still updating while the alarm rings, then the music should be playing but muted. This should be the current behaviour of the audio channel, the muted channel is still playing. Unless the audio channel pauses the audio element or music app should not stop updating the progress bar.

I will first reassign it to system component because this seems related to the audio competing issues.

	Dominic Kuo [:dkuo]
	Comment 5 • 11 years ago

Update:

This behaviour is changed since the audio competing policy has updated. In 1.3, after the user press home button to ignore the alarm while music app is also playing in the background, then bring music app to the foreground, the sounds of alarm and music will be mixed together, that's, we can hear both the alarm and music even the alarm window is minimized in the status bar.

As described above, it seems we can change the behaviour to avoid this issue, and get better user experiences as well, like snooze/mute the alarm once the user press the home button, then alarm and music won't be able to be heard at the same time.

We will need some ux inputs if we want to fix this by changing the alarm's  behaviour, cc'ing Juwei to catch her attention.

	Marcus Cavanaugh [:mcav] Assignee
	Comment 6 • 11 years ago

Juwei, do we want to snooze/mute the alarm when the user presses the home button?

	Juwei Huang[:juwei]
	Comment 7 • 11 years ago

The music should pause when the alarm go off, indeed.
However, this situation is more about what alarm will happen when tap on the home button. My suggestion would be snooze the alarm since it makes no sense that the alarm still ringing after the user does some actions. It is supposed to cancel or snooze the alarm at the moment. 
So I am more prefer to snooze the alarm just in case people miss it and discard the alarm banner over the top of screen right now.
Here's the flow:
Play music in the background -->Alarm goes off, pause the music --> Tap on home button --> Snooze the alarm, play music.

	Dominic Kuo [:dkuo]
	Comment 8 • 11 years ago

[UX_TRIAGED]

As Juwei commented in comment 7, we will go for the approach.

I don't know the clock code, but I guess the possible solution could be the alarm listen to the |resize| event, once the window is being minimized, then alarm should know the home button is pressed and triggered the window to be resized, then snooze the alarm, it sounds like we can have this in 1.4.

Marcus, I am nominating this bug to 1.4 because in the offline audio competing meeting, ux team thought this is a simple fix that give better ux, and won't give too many effort for dev, but if you think it's not going to happen in 1.4, please let us know and let's have this in the later version, thanks.

	Marcus Cavanaugh [:mcav] Assignee
	Comment 10 • 10 years ago

Fixed in bug 996092 per Juwei's recommendation in Comment 7.