809087 - [Clock] Turn off the active alarm (screen + sound) automatically when there is a incoming phone call

Status: VERIFIED FIXED

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

Description

[Gene Lian (I already quit Mozilla)]

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.

Comment 1

[Gene Lian (I already quit Mozilla)]

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.

Comment 2

[Josh Carpenter [:jcarpenter]]

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.

Comment 3

[Josh Carpenter [:jcarpenter]]

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

Comment 4

[Gene Lian (I already quit Mozilla)]

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

Comment 5

[Josh Carpenter [:jcarpenter]]

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.

Comment 6

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

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

Comment 7

[Josh Carpenter [:jcarpenter]]

Hi Ian. I believe so, yes.

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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?

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

Comment 10

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

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.

Comment 11

[Tony Chung [:tchung]]

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

Comment 12

[Josh Carpenter [:jcarpenter]]

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

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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.

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

Comment 17

[Andrew Overholt [:overholt]]

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?

Comment 18

[Marco Chen [:mchen]]

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.

Comment 19

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

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

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 21

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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.

Comment 22

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

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6992

Pointer to Github pull-request

Comment 23

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

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 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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 25

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

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 26

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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 27

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

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.

Comment 28

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

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

Comment 29

[John Shih]

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"