Based on Ian's mention, how long an alarm rings and vibrates is currently hard-coded in the Clock app for testing purposes. We need UX's supports to further define them.

Hi :patryk, Per Ian, we need to define the Alarm's behaviours at comment #0. Are you the right UX guy to do this? Temporally assign this to you. Please feel free to reassign it to someone else. Thanks! For me, I don't think the current Alarm can wake people up because it only rings for a dozen of seconds before users can notice that.

Hi Gene, I can take this. The alarm should ring for 15 minutes. That's a long time, but I'd prefer to err on the side of long-and-annoying than to risk someone not hearing a too-short alarm.

Why am I the assignee? A dev will need to make this change.

Sorry Josh! I saw you were saying you can take this at comment #2 so I directly assign this to you. I probably misunderstood?

Ah I see. Sorry for the confusion, Gene. I meant that I could answer the question :) Someone else will need to implement the actual code.

(In reply to Josh Carpenter [:jcarpenter] from comment #2) > Hi Gene, I can take this. The alarm should ring for 15 minutes. That's a > long time, but I'd prefer to err on the side of long-and-annoying than to > risk someone not hearing a too-short alarm. Hi Josh, do we need to vibrate when alarm goes off?

Hi Ian. I believe so, yes.

Triage: this should be considered the meta bug to implement the overall behavior of clock app when alarm sounds. (In reply to Josh Carpenter [:jcarpenter] from comment #2) > Hi Gene, I can take this. The alarm should ring for 15 minutes. That's a > long time, but I'd prefer to err on the side of long-and-annoying than to > risk someone not hearing a too-short alarm. According to the comment, the behavior defined by UX would be ring (and kept the screen on) continuously for 15 min. What if the user didn't turn off the alarm after 15 min? Do we automatically trigger sneeze afterwards?

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #8) > Do we automatically trigger sneeze afterwards? According to Ian, UX has defined that if the alarm was kept on for 15 min, it should go away quietly. My question to that would be: isn't that the current confusing behavior, which the user will think the alarm didn't sound at all?

Hi Josh and Tim, I summarize the confusing behavior. We still need more information for the overall behavior. Q: (1) What if the user didn't turn off the alarm after 15 min? Do we automatically trigger sneeze afterwards? (2) How is the behavior for incoming phone case during the alarm goes off?(Obviously, turning the alarm ringtone and vibration off. Then, the attention of alarm goes off page is waiting for user to make their selection after incoming phone is finished. Is it right?) Is there any behavior which are not considered by me? Please feel free to figure out them. Thank you.

Leaving this as basecamp-blocking? Sounds like an design bug, so please comment quickly what the solution is so triage can + or - it.

(In reply to Ian Liu [:ianliu] from comment #10) > (1) What if the user didn't turn off the alarm after 15 min? Do we > automatically trigger sneeze afterwards? Let's do this. After an alarm has been active for 15 minutes: * Turn alarm sound off * Turn alarm vibration off * Keep alarm on * Keep Active Alarm screen on The next time the user picks up the device, they will see that they've missed an alarm, even if the ringing has stopped by that point. In future versions we can look at designing a "you missed an alarm" screen, but that's out of scope for v1. > (2) How is the behavior for incoming phone case during the alarm goes > off?(Obviously, turning the alarm ringtone and vibration off. Then, the > attention of alarm goes off page is waiting for user to make their selection > after incoming phone is finished. Is it right?) If device is locked, alarm is active, and a phone call is received: * Turn alarm sound off * Turn alarm vibration off * Turn alarm off * Turn Active Alarm screen off * Turn incoming call sounds/vibration on If user answers call, then there's no need for them to know about the alarm. If the user misses the call, the next time they turn on the phone they'll see the lock screen and a "missed call" notification, which is more important information than the missed alarm, IMO. We can always revisit in v2, but I think this should work well for v1. Have I missed anything?

In order to detect the incoming call, we would need mozinterrupt event from MozAudioChannel API. After that, the onring alarm screen can simply close itself.

Correction: mozinterrupt event happens on the <audio> element, not the AudioChannel Application API.

With bug 817485 and bug 805333 landing, the "covered" alarm attention screen will not be able to vibrate() or play the sound; vibrate() is disconnected because the frame will be set to setVisible(false) (bug 817485) and the sound channel is muted (bug 805333). However, Ian, you will still need to correct the behavior on the time when user hang up the phone and the alarm attention screen leaves the "covered" state.

The related bug (phone call in progress -> alarm fire) is bug 814632.

Now that bug 805333 has been fixed, we think the sound portion of this bug is fixed. If so, we can probably morph this bug into just being about the screen bit. Can someone verify the audio part?

About audio part, this bug also depends on bug 815322 (which depends on 805333). 815322 added the ringer type for ring tone of incoming call and it's priority is higher then alarm.

I will help to verify the audio issue when bug 815322 are landed.

This should be fix now, but would be great to get that verified.

See comment 15. While platform & Gaia system changes on sound and visibility will prevent the ring screen from annoying user, the Clock app should still be responsive to these state changes.

Pointer to Github pull-request

Comment on attachment 691706 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6992 1. Bug 809087 - [Clock] Turn off the active alarm (screen + sound) automatically when there is a incoming phone call * Receive mozinterruptbegin event to turn the active alarm off. 2. Bug 814632 - [Clock] Put a "silent" alarm screen underneath the oncall screen if the alarm goes off during a phone call * Do a lazily check mozHidden in init state since Bug 810431 isn't fixed yet. * The workaround is used in screen off mode only.

Comment on attachment 691706 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6992 Please fix according to comment addressed, discuss with me offline if necessary, and re-request for review. You are almost there :)

Comment on attachment 691706 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6992 Revise the patch according Tim's comment in Github.

Comment on attachment 691706 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6992 r=me with comments addressed. If you are unsure please talk to me.

Comment on attachment 691706 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6992 Tim, I simplify the patch again. I'm unsure that you'll agree or not. Please review it again. Thank you.

Since the pr(https://github.com/mozilla-b2g/gaia/pull/6992) is merged, we can close the issue now.

The bug has been fixed, but I found another related bug, please see bug 823399 verified on 2012-12-20-unagi build info: 2012-12-18 unagi release build gecko revision: "1527cf5192e32a1864dd47e38bfa8de7adf735ab" gaia revision: "2b77f0a3fcc862c6925138d08fe44576da56bc7"