823399 - [Clock] After cancel an incoming call when there is an active alarm, the alarm will keep ringing with no alarm page

Status: VERIFIED FIXED

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

Description

[John Shih]

## Environment :
Unagi phone, release build 2012-12-18
Build info: 
gaia master : 1527cf5192e32a1864dd47e38bfa8de7adf735ab
mozilla-beta : 2b77f0a3fcc862c6925138d08fe44576da56bc7

## Repro :
1. Set an alarm
2. Wait for alarm goes off
3. Make a phone call from other device
4. The incoming call will ring, verify the alarm is turned off
5. Cancel the incoming call 

## Expected:
* According to bug 809087, the active alarm (page + sound) will be turned off

## Actual:
* Didn't see the alarm page, but the alarm keep ringing

Comment 1

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

(In reply to John Shih from comment #0)
> ## Environment :
> Unagi phone, release build 2012-12-18
> Build info: 
> gaia master : 1527cf5192e32a1864dd47e38bfa8de7adf735ab
> mozilla-beta : 2b77f0a3fcc862c6925138d08fe44576da56bc7
> 
> ## Repro :
> 1. Set an alarm
> 2. Wait for alarm goes off
> 3. Make a phone call from other device
> 4. The incoming call will ring, verify the alarm is turned off
> 5. Cancel the incoming call 
> 
> ## Expected:
> * According to bug 809087, the active alarm (page + sound) will be turned off

AFAIK, the alarm page would be still there under call screen without ringing. Don't know what 'turn off' means :P

> 
> ## Actual:
> * Didn't see the alarm page, but the alarm keep ringing

Comment 2

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

As far as I know this is expected behavior for v1.

You will have to switch to the alarm app and stop the audio there. Just like you would have to switch to the music app and stop the audio there after rejecting a call.

Bug 809087 was just about silencing the alarm *while* there was an incoming phonecall.

Comment 3

[John Shih]

Alive, 
now we have different behavior on
1) alarm goes off first, and then incoming call rings
2) The incoming call rings first, and during the rings, the alarm goes off

What you describe is the behavior of 2) 

Jonas,
I know what you mean
but now after cancel the incoming call, switch to clock app will just see the normal clock page (there is no button or something to stop the alarm)
the only way is  launch the card view and kill the clock app :'(
so this one must be a bug

Comment 4

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

(In reply to John Shih from comment #3)
> Jonas,
> I know what you mean
> but now after cancel the incoming call, switch to clock app will just see
> the normal clock page (there is no button or something to stop the alarm)
> the only way is  launch the card view and kill the clock app :'(
> so this one must be a bug

John, thanks for clarifying. 
More clear now. I believe this is an attention screen bug. Taking.

Comment 5

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

According the reproduced steps, it is relative with Comment 3 
case 1) alarm goes off first, and then incoming call rings.

I find out some regression comes from window.close().
When the onring page received "mozinterruptbegin" event, we'll turn off the active alarm and do window.close() for the onring page. If the window is closed, the audio tag should not be playback. I have some test for the case last week. But it does not work now.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB+, C3, P3 - severe usability - could be embarrassing not be able to stop alarm

Comment 7

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

I am wrong...this sounds like platform issue? c.c. mchen rlin

Comment 8

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

The intended behavior from a platform point of view is that the alarm audio channel *should* be unpaused as soon as the telephony channel no longer used.

So from a platform point of view it seems like things are working as designed.

Ensuring that there is UI for turning the alarm off is a UI issue.

Likewise, if we want to stop the alarm <audio> as soon as it's paused by the telephony channel, that needs to be done in the UI too.


Am I missing something?

Comment 9

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

Here is an UI decision to close alarm initiatively if the call is coming after alarm goes off.

Problem happening here is the closed window is already removed from DOM tree by window.removeChild() but the audio element in the removed window is still playing.

Comment 10

[John Shih]

yes, according to the bug 809087, alarm (sound+page) should be turned off, i.e, after the phone call, the alarm is no longer exist

Comment 11

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

I think that the root cause is the method of window.close().
(Such as Alive's comment 9) 

Please reference comment 5 for the UI decision when onring page received "mozinterruptbegin" event. We do window.close() directly without pause the audio tag.

If the platform issue cannot be fixed easily, I can pause the audio tag with another patch. But the issue could be still there.

Comment 12

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

I see. Is this another instance of bug 820704 then?

Or are we somehow not properly unregistering media elements when their window is closed?

My money is on bug 820704, but it'd be good to get that verified.

Comment 13

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

Jonas,
Thank for your information with relative bug 820704.

I will take over the issue with a workaround. Since it's a C3 issue, let's pause the audio tag before window.close(). We will verify or create another issue when bug 820704 is fixed.

Comment 14

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

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

Pointer to Github pull-request

Comment 15

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

Comment on attachment 695438 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7173

r=me

Comment 16

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

Since the pr https://github.com/mozilla-b2g/gaia/pull/7173 is merged, close the issue now.

Comment 17

[John Shih]

verified on unagi 12/25
build info
gaia master: 1be7bf421a6498f6e73377e3028227dea99b3431
b2g-18: e261861b0270