883717 - [clock] Alarm sounds and the music is played at the same time.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Clock, defect, P1)

Description

[Leo]

1. Title : Alarm sounds and the music is played at the same time.
2. Precondition : 
3. Tester's Action :1. Set alarm
                   :2.Playing music
                   :3.After setting the alarm to play music.
                   :4.The alarm is sounding, press the Home button to   switch
                      to music tab.
4. Detailed Symptom (ENG.) : After setting the alarm to play music. The alarm           is sounding, press the Home button to switch to the Music tab.
Alarm sounds and the music is played at the same time.

6. Expected : when Alarm is ring music should not be sound.
7. Reproducibility: Y
1)Frequency Rate : 100%

Comment 1

[Marco Chen [:mchen]]

Hi Leo,

I think it is under the design now because there is a rule of all foreground window can play sound no matter it's audiochannel type or any other highest priority channel there.

Can you confirm this rule or we need UX inputs here? Thanks.

Comment 2

[[e-mail], [e-mail]]

cc relative devs. I'm not sure the foreground window rule is defined and noted in wiki page or not. https://wiki.mozilla.org/WebAPI/AudioChannels
I just know the rule..

Comment 3

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

Is this real a bug?
Some android device dismiss the alarm when home is pressed.
Some android device plays the music and the alarm at the same time(But alarm is really louder than music so music playing is ignored).

Comment 4

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

See comment 1, comment 3.
I'd like to ask leo? on this one because I don't this is a bug nor blocking.

The only thing we could do: close the alarm once home button is pressed to avoid the app playing audio at the same time.

Comment 5

[Leo]

we check android behavior when Home button press then Alarm goes to snooze..
so alarm snoozed when home button is pressed.

Comment 6

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

^ Ian, would we regress something is alarm goes snooze when it gets window.resize event?

Comment 7

[[e-mail], [e-mail]]

Do you means that snooze the alarm when alarm goes off and user click home button? It will receive window.resize event in attention status bar mode. I think there won't be any regress for the solution. But why do we need to implement attention status bar style. We could never see that again since always snooze it in this case. It would be better with UX's input here.

Comment 8

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

(In reply to Ian Liu [:ianliu] from comment #7)
> Do you means that snooze the alarm when alarm goes off and user click home
> button? It will receive window.resize event in attention status bar mode. I
> think there won't be any regress for the solution. But why do we need to
> implement attention status bar style. We could never see that again since
> always snooze it in this case. It would be better with UX's input here.

Yes, need UX input but would like to know if there's some problems programmatically if we decide to do this..

Comment 9

[[e-mail], [e-mail]]

In case of phone call coming, the symptom is same with alarm. If we decide this is an issue and request UX's input, I propose UX should consider music vs alarm/call together.

Comment 10

[[e-mail], [e-mail]]

We need UX input here to decide it an issue or not.

Comment 11

[Stephany Wilkes]

Assigning this leo+ to Casey to advise on whether or not UX input is even needed. :)

Comment 12

[Casey Yee]

This isn't really a bug, and certainly not important enough to be blocking.

As mentioned already in Comment 1, the foreground app always has the ability to make sounds regardless of channel.  This same scenario is also present when a user answers a incoming call and decides to play music/media while on the call.   

I also think that the proposal to key the snooze function while the alarm is sounding makes sense.    I wouldn't turn the alarm off though since users may end up missing their alarms (I know I would!).   Please open a separate bug for this feature.   

I'm going to mark this bug "Won't fix" since the behavior is as intended.