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)
Tracking
(blocking-basecamp:+)
People
(Reporter: johnshih.bugs, Assigned: iliu)
References
Details
Attachments
(1 file)
## 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•12 years ago
|
||
(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
Comment 4•12 years ago
|
||
(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
Assignee | ||
Comment 5•12 years ago
|
||
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•12 years ago
|
||
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)
Updated•12 years ago
|
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?
Comment 9•12 years ago
|
||
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.
Reporter | ||
Comment 10•12 years ago
|
||
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
Assignee | ||
Comment 11•12 years ago
|
||
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.
Assignee | ||
Comment 13•12 years ago
|
||
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
Updated•12 years ago
|
Comment 15•12 years ago
|
||
Comment on attachment 695438 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7173 r=me
Attachment #695438 -
Flags: review+
Assignee | ||
Comment 16•12 years ago
|
||
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
Reporter | ||
Comment 17•12 years ago
|
||
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.
Description
•