814914 - [FM Radio] Clicking stop button with both radio and music app playing causes phone to lock up and reboot

Status: VERIFIED FIXED

(Core :: DOM: Device Interfaces, defect, P2)

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

I was listening to the radio and decided to click to play an mp3 in the music app. I expected that the radio would stop and I would only hear the mp3 but instead I heard both. That's ok. However, when I returned to the radio app and clicked the stop button the phone locked up and then rebooted. I was able to reproduce this multiple times.

STR
1. Open the radio app and select a frequency.
2. Open the music app and start to play an mp3. At this point both the radio and mp3 should be audible.
3. Return to the radio app and click stop.

Expected
The radio should stop playing when I click stop in the radio app. The mp3 should continue to play.

Actual
The phone locks up and subsequently reboots.

stable build 2012-11-14 09:49:28

Comment 1

[Marco Chen [:mchen]]

(In reply to Lawrence Mandel [:lmandel] from comment #0)
> I was listening to the radio and decided to click to play an mp3 in the
> music app. I expected that the radio would stop and I would only hear the
> mp3 but instead I heard both. That's ok. 

Once Bug 805333 (audio competing policy) is completed, your expectation will be true.

> Expected
> The radio should stop playing when I click stop in the radio app. The mp3
> should continue to play.
> 
> Actual
> The phone locks up and subsequently reboots.
> 
> stable build 2012-11-14 09:49:28

But this one would be better to fix before Bug 805333 landed.

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Not a Gaia bug. Sounds like a gecko issue.

Comment 3

[Andrew Overholt [:overholt]]

Marco/Andrea, could this be fixed by the audio API you're working on?

Comment 4

[Andrea Marchesini [:baku]]

I think it's not related.

Maybe with the new audio API this bug is not reproducible but I think it's better to fix it before landing Bug 805333.

Comment 5

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 6

[Dietrich Ayala (:dietrich)]

Hi Randy, no update here since you were assigned the bug ~10 days ago. When do you expect a fix to be available?

Comment 7

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Michael, 
Have you updated the tweak kernel which provided by partner and updated on release process?

Comment 8

[Andrew Overholt [:overholt]]

I can confirm this bug persists with a 2012-12-16 nightly on my Unagi.

Comment 9

[Michael Wu [:mwu]]

FTR, there was a kernel update last week.

Comment 10

[John Shih]

This bug seems like a dup of Bug 797698, and it should be fixed by the kernel update
I can't reproduce anymore

Randy, can you confirm this?

Comment 11

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Yes, mwu has phase in new kernel message last week.

Comment 12

[John Shih]

closing and tag verified
build id: 20121220092540