355 bytes, text/html
## 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
(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.
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
I am wrong...this sounds like platform issue? c.c. mchen rlin
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.
Created attachment 695438 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7173 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
Since the pr https://github.com/mozilla-b2g/gaia/pull/7173 is merged, close the issue now.
verified on unagi 12/25 build info gaia master: 1be7bf421a6498f6e73377e3028227dea99b3431 b2g-18: e261861b0270