Closed Bug 823399 Opened 12 years ago Closed 12 years ago

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

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::Clock
Platform:
x86_64
Windows 7
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
VERIFIED FIXED
Milestone:
B2G C3 (12dec-1jan)
Project Flags:
blocking-basecamp +

People

(Reporter: johnshih.bugs, Assigned: iliu)

References

Details

Attachments

(1 file)

Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7173
(deleted), text/html
timdream
: review+
Details 
## 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
blocking-basecamp: --- → ?
(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
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.
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
(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.
Assignee: nobody → alive
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.
Triage: BB+, C3, P3 - severe usability - could be embarrassing not be able to stop alarm
blocking-basecamp: ? → +
Priority: -- → P3
Target Milestone: --- → B2G C3 (12dec-1jan)
I am wrong...this sounds like platform issue? c.c. mchen rlin
Assignee: alive → nobody
Component: Gaia::Clock → General
QA Contact: jshih
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?
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.
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
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.
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.
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.
Assignee: nobody → iliu
Component: General → Gaia::Clock
Depends on: 820704
QA Contact: jshih
Pointer to Github pull-request
Comment on attachment 695438 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7173

r=me
Attachment #695438 - Flags: review+
Since the pr https://github.com/mozilla-b2g/gaia/pull/7173 is merged, close the issue now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
verified on unagi 12/25
build info
gaia master: 1be7bf421a6498f6e73377e3028227dea99b3431
b2g-18: e261861b0270
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: