1075353 - 1st inline activity is not killed before the second inline activity comes.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[ranjith253]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:


1. Open music->play any song->receive a file via Bluetooth->wait for download complete->drag notification->Play downloaded file.

2.Press Home key-> Receive one more music file via Bluetooth->wait for download complete->drag notification->Play downloaded file.




Actual results:

Music player hangs , user cannot access any player controls.


Expected results:

Music player should play the received file properly

Comment 1

[ranjith253]

Hi wayne,

Can you help me by getting some one who can look in to this issue?

Thanks.

Comment 2

[Rachelle Yang [:ryang][[e-mail]]]

Hi, please provide the detailed build information (below)and video STR otherwise we won't proceed the issue any further.
including 
gaia revision
gecko revision
build-ID 
gecko version
firmware version
occurrence rate 

thank you very much.

Comment 3

[Rachelle Yang [:ryang][[e-mail]]]

[Blocking Requested - why for this release]:
partner requested as blocker.

Comment 4

[ranjith253]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #2)
> Hi, please provide the detailed build information (below)and video STR
> otherwise we won't proceed the issue any further.
> including 
> gaia revision
> gecko revision
> build-ID 
> gecko version
> firmware version
> occurrence rate 
> 
> thank you very much.


As the issue scenario takes long time , I cannot share video of large size.
I am attaching issue screen shot .
Issue is reproducible on flame device.

gaia revision : v2.0
build-ID : 20141002170510 
gecko version: 32.0
occurrence rate: 100%

Thank you.

Comment 5

[ranjith253]

Attachment: issuescreenshot

Comment 6

[Dominic Kuo [:dkuo]]

System app should kill the previous music open activity then keep the current one, so this should be an issue under the system component, might already fixed in master branch.

Comment 7

[Rachelle Yang [:ryang][[e-mail]]]

Hi Alive, per comment 6, could you please provide your comments and feedback ? 
Thank you very much !

Comment 8

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

qawanted for master

Comment 9

[Rachelle Yang [:ryang][[e-mail]]]

Hi star, 
Could you please kindly look into this issue ? Will it be related to bug1003025/ bug1062144 ?
Thank you very much !

Comment 10

[Dominic Kuo [:dkuo]]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #9)
> Hi star, 
> Could you please kindly look into this issue ? Will it be related to
> bug1003025/ bug1062144 ?
> Thank you very much !

Hi Rachelle, I think this issue is more related to the window management under system app, so Star is probably not the person your are looking for, let's see if this bug is fixed on master or not, thanks!

Comment 11

[Safwan Rahman (:safwan)]

It can be reproduced in latest maser V2.2

Environmental Variables:
Device: Keon V2.2
BuildID: 20141008012326
Gaia: 68b8bc9
Gecko: 652c5d4
Version: 35.0a1

Comment 12

[Joshua Mitchell (Inactive)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #8)
> qawanted for master

QA-Wanted request satisfied by comment 11 (Thanks Safwan!) - 

Also flipping 2.0 to affected per comment 4

Comment 13

[Wayne Chang [:wchang]]

looks like rachelle has taken care here.

Comment 14

[Rachelle Yang [:ryang][[e-mail]]]

Hi Dominic, per comment 11, it seemed the issue is reproducible on master.
Do you have any idea we could proceed to work on this ?
Thank you very much!

Comment 15

[Dominic Kuo [:dkuo]]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #14)
> Hi Dominic, per comment 11, it seemed the issue is reproducible on master.
> Do you have any idea we could proceed to work on this ?
> Thank you very much!

If it's still reproducible on master(according to comment 11) then this is an system window management issue, let's have Alive to help on this, Alive, would you please take a look? thanks!

Comment 16

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

Transfer to George.

Comment 17

[Rachelle Yang [:ryang][[e-mail]]]

Hi safwan,
 
Per comment 11, is the issue easily reproduced? 
Could you please kindly provide the detailed STR and the reproduce rate for our reference? 
Thank you very much.

Comment 18

[Safwan Rahman (:safwan)]

Thanks for the NI. As per comment 17, I am providing all the information. 
In the latest master build, this issue can be slightly reproduced. I am giving STR below.

# Turn on the Bluetooth of the Device and pair any other Device.
# Open the Music app and play any music
# While playing the music, transfer any Audio file from the paired device to your Firefox OS device with Bluetooth.
# Accept the file transfer and the file will be downloaded into your Device.
# After transfer complete, Drag down the Notification bar and play the downloaded Audio file.
# While playing the downloaded file, send another Audio file to the Firefox OS Device
# Accept the file transfer and the file will be downloaded into your Device.
# After transfer complete, Drag down the Notification bar and play the downloaded Audio file.

Actual Result:
# The Audio File will not be played

Expected result:
# The Audio File should be played
 
Reproduce rate: 5/5

Interesting fact is, in the build of 20141008012326 which environment I used in comment 11, if this steps are taken, the Media player hangs. (As mentioned in the bug)

But, in the build which I am using now (20141012161832), the music player does not play the music.


Environmental Variables:
Device: Keon V2.2
BuildID: 20141012161832
Gaia: 717ad4e8b7fc10ab8248500d00ba5ba0977fa8ab
Gecko: ad3210dd8e400d91fd115fd18f40c45f0ece3c1e
Version: 35.0a1

Comment 19

[Rachelle Yang [:ryang][[e-mail]]]

Triage to set it to 2.0+ ; 100% reproduce rate,reproducible on master, besides partner requested this as blocker.

Comment 20

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to master

Hi Alive,
please kindly check my proposal for this bug. 
Thanks.

Comment 21

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

Comment on attachment 8506001 [details] [review]
PR to master

terminated means activity is already in the terminating process, and it is expected  to call destroy on its own, please investigate why destroy is not called. (Because it's not closed?)

Comment 22

[(Inactive after June) George Duan [:gduan] [:喬智]]

I think the root cause is, when we get 2nd activity requesting and launch it, we call activity.kill() on the old one but it takes time to close it since it's still active in the background. So, two activities may exist at the same time and cause this bug. 
However, I can't reproduce it on my cellphone after flashing 20141008040203 build.

Can anyone help to test if it's still reproducible on master and verify my gaia patch?
Thanks.

Comment 23

[Safwan Rahman (:safwan)]

George,
I have tested it in 20141012161832, see comment 18 and it seems to be happen there. Can you please test again according to the STR of comment 18 which I provided?

There is 2 actual result outcome in 2 version.
1. In Master build 20141008012326, The player hangs after doing the steps. see comment 11
2. In Master build 20141012161832, The player does not play the next song. see comment 18

Comment 24

[(Inactive after June) George Duan [:gduan] [:喬智]]

I just tested today's central build and found out that I can reproduce it with mp3 file but cannot with ogg file.

Comment 25

[(Inactive after June) George Duan [:gduan] [:喬智]]

When launching ogg file from bluetooth, we actually open video's app instead of music, that's why the behavior looks different. I observe that video app monitor visibility change and do postResult, that's why activityWindow can get mozbrowseractivitydone event and call kill.

Should do the same thing in music app (open.js)?

Comment 26

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8506001 [details] [review]
PR to master

Hi Dominic, 
Please kindly see my comment 25. I think we should do postResult when visibilityChange, just like video app, then the background activity will be killed correctly when pressing home. What do you think?

Comment 27

[(Inactive after June) George Duan [:gduan] [:喬智]]

I also modify part of app_window.js for comment 22.

Comment 28

[Dominic Kuo [:dkuo]]

Comment on attachment 8506001 [details] [review]
PR to master

Thanks George!!! I don't know the open activity should postResult when it goes to background, and since the video app did this, it make sense that music app does this as well, let's fix it :)

Comment 29

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8506001 [details] [review]
PR to master

Hi Alive,
could you kindly review it? I think the reason is as comment 25.

Comment 30

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

Comment on attachment 8506001 [details] [review]
PR to master

r+ with nit(and test wanted with it) thanks!

Comment 31

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to v2.1

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): No.
[User impact] if declined: Cannot play 2nd received file from inline activity.
[Testing completed]: yes.
[Risk to taking this patch] (and alternatives if risky): No
[String changes made]:

Comment 32

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to 2.0

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): No.
[User impact] if declined: Cannot play 2nd received file from inline activity. Please see comment 0.
[Testing completed]: yes.
[Risk to taking this patch] (and alternatives if risky): No
[String changes made]:

Comment 33

[(Inactive after June) George Duan [:gduan] [:喬智]]

Master: https://github.com/mozilla-b2g/gaia/commit/c7144a9c6ebaa27df4188bea85191c29af3ded25

Comment 34

[ranjith253]

Hi George,

After testing the given patch on v2.0 branch I have identified following issue.

1.Open music app , play any song. 
2.Send a file a.mp3 via Bluetooth.
3.After download complete play a.mp3 file from notification .
4.Stay on the same open activity window.
5.Send file b.mp3 while listening to a.mp3 via Bluetooth.
6. After download complete play b.mp3 file from notification.

Actual result
a.mp3 file is played 

Expected result
b.mp3 file should be played.

Can you please check this behaviour & confirm it ?

Thanks.

Comment 35

[(Inactive after June) George Duan [:gduan] [:喬智]]

Hi,
my patch only fix comment 0 which is different with comment 34.

In comment 34, user doesn't switch app, so gaia doesn't know what activity we should close after new activity is created.

We should file a new bug for gecko to fix that.

Comment 36

[Safwan Rahman (:safwan)]

George, thanks for your nice work into this,
I think the issue described in comment 0 was fixed in 2.2 according to comment 18. I have made a conclusion of the problem in comment 23. Please check that also.

> There is 2 actual result outcome in 2 version.
> 1. In Master build 20141008012326, The player hangs after doing the steps.
> see comment 11
> 2. In Master build 20141012161832, The player does not play the next song.
> see comment 18

So, I think the problem which is described in comment 23 and comment 34, was fixed in Gecko: ad3210dd8e400d91fd115fd18f40c45f0ece3c1e, Version: 35.0a1

as its a bug of Gecko, can you please describe what result you get when you do this in Firefox OS 2.2 with the patch?

Comment 37

[Safwan Rahman (:safwan)]

Is it possible to find the first gecko Version where its solved?
The gecko version should be within this following build, I hope it will be easier to triage it.

Affected:
BuildID: 20141008012326
Gaia: 68b8bc9
Gecko: 652c5d4
Version: 35.0a1

Not affected:
BuildID: 20141012161832
Gaia: 717ad4e8b7fc10ab8248500d00ba5ba0977fa8ab
Gecko: ad3210dd8e400d91fd115fd18f40c45f0ece3c1e
Version: 35.0a1

Comment 38

[[:fabrice] Fabrice Desré]

(In reply to George Duan [:gduan] [:喬智] from comment #33)
> Master:
> https://github.com/mozilla-b2g/gaia/commit/
> c7144a9c6ebaa27df4188bea85191c29af3ded25

George, please close bugs when you land on master.

Comment 39

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment 34 should be different bug with comment 0, because we don't actually kill previous activity when open music file from bluetooth for the second time, instead, we do nothing but let app itself to update its content through navigator.mozSetMessageHandler listener. 

I just tested on gallery and it works just fine.

Hi Dominic,
do you have any idea on that?

Comment 40

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I am still able to reproduce this issue as written in comment 0 in the latest 2.2 build.  Please note that returning to the homescreen is necessary to reproduce this issue with an unresponsive music app.  I also see that following the steps in comment 18 will not play the song, but will also not cause an unresponsive music app.  As the results are different and both reproducable, should that not be a separate bug instead?

Steps to reproduce:
1) Update a Flame to 20141020055012
2) Pair with another device that has at least two songs in the music app.
3) Begin playing a song
4) Send a song from the device in step 2 and play it when recieved.
5) Return to the homescreen
6) Send another song from the device in step 2 and play it when recieved.

Actual Results:
The music app becomes unresponsive and does not play he song.

Expected Results:
The song is played.

Environmental Variables:
Device: Flame 2.2
BuildID: 20141020055012
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: f2d7d694aae5
Version: 36.0a1 (2.2) 
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 41

[(Inactive after June) George Duan [:gduan] [:喬智]]

I saw music app (open.js) did receive two different request.source.data.filename from mozSetMessageHandler, however, the playing music wasn't updated to the 2nd one.

(In reply to George Duan [:gduan] [:喬智] from comment #39)
> Comment 34 should be different bug with comment 0, because we don't actually
> kill previous activity when open music file from bluetooth for the second
> time, instead, we do nothing but let app itself to update its content
> through navigator.mozSetMessageHandler listener. 
> 
> I just tested on gallery and it works just fine.
> 
> Hi Dominic,
> do you have any idea on that?

Comment 42

[(Inactive after June) George Duan [:gduan] [:喬智]]

My patch should have solve your STR. The gaia commit dc496d04907dd314f9736ff78bab3bd27156f79a you're using doesn't have my patch yet.

(In reply to Jayme Mercado [:JMercado] from comment #40)
> I am still able to reproduce this issue as written in comment 0 in the
> latest 2.2 build.  Please note that returning to the homescreen is necessary
> to reproduce this issue with an unresponsive music app.  I also see that
> following the steps in comment 18 will not play the song, but will also not
> cause an unresponsive music app.  As the results are different and both
> reproducable, should that not be a separate bug instead?
> 
> Steps to reproduce:
> 1) Update a Flame to 20141020055012
> 2) Pair with another device that has at least two songs in the music app.
> 3) Begin playing a song
> 4) Send a song from the device in step 2 and play it when recieved.
> 5) Return to the homescreen
> 6) Send another song from the device in step 2 and play it when recieved.
> 
> Actual Results:
> The music app becomes unresponsive and does not play he song.
> 
> Expected Results:
> The song is played.
> 
> Environmental Variables:
> Device: Flame 2.2
> BuildID: 20141020055012
> Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
> Gecko: f2d7d694aae5
> Version: 36.0a1 (2.2) 
> Firmware Version: v180
> User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 43

[Safwan Rahman (:safwan)]

I have filled another bug about comment 18 and comment 34

https://bugzilla.mozilla.org/show_bug.cgi?id=1085380

Jayme, can you please test with the of 21th October? or any build which having the mentioned commit?

Comment 44

[Dominic Kuo [:dkuo]]

Let's followup in bug 1085380.

Comment 45

[Safwan Rahman (:safwan)]

marking as "verifyme" for verifying in 2.0, 2.1 and 2.2

Please check the STR which provided in comment 0. not in comment 34 :)

Comment 46

[Safwan Rahman (:safwan)]

George,
It seems that it has raised another issue!

# Get a audio file over bluetooth.
# Play the file
# tap on home button

Actual result:
# The music stop playing

Expected result:
# The music should keep playing

Comment 47

[Safwan Rahman (:safwan)]

I am reopening this bug as its depends on another bug.

Comment 48

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Although the patch does fix this issue, the new issue that it causes (stopping the music when returning ot the homescreen) could be considered just as bad.

Environmental Variables:
Device: Flame 2.2
BuildID: 20141021125333
Gaia: 82174cee5ede9f23aedad8a39f8b8cdc1ae710c4
Gecko: 7cbe04116653
Version: 36.0a1 (2.2) 
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 49

[Dominic Kuo [:dkuo]]

(In reply to Jayme Mercado [:JMercado] from comment #48)
> Although the patch does fix this issue, the new issue that it causes
> (stopping the music when returning ot the homescreen) could be considered
> just as bad.
> 
> Environmental Variables:
> Device: Flame 2.2
> BuildID: 20141021125333
> Gaia: 82174cee5ede9f23aedad8a39f8b8cdc1ae710c4
> Gecko: 7cbe04116653
> Version: 36.0a1 (2.2) 
> Firmware Version: v180
> User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

The music open activity does not provide full functionalities, it acts like a previewer to preview audio files, such as the attachments in sms and email, or the received files from bluetooth, so this bug is actually a regression, and we just fixed it, not introducing another new issue.

You can try the versions before v2.0(e.g v1.4), it's easy to reproduce that the music open activity will be closed immediately right after you press the home button.(I have also commented this in bug 1086280 comment 1)

Comment 50

[Safwan Rahman (:safwan)]

Dominic,
Thanks for your comment. can you please check the comment 40 ?
According to it, the song is playing still after going to home button. That means, before going this patch to Master brunch, the player was playing the song though user go to the home screen. So I think this patch introduced that issue.
So I think this should be fixed!

Comment 51

[Dominic Kuo [:dkuo]]

(In reply to Safwan Rahman from comment #50)
> Dominic,
> Thanks for your comment. can you please check the comment 40 ?
> According to it, the song is playing still after going to home button. That
> means, before going this patch to Master brunch, the player was playing the
> song though user go to the home screen. So I think this patch introduced
> that issue.
> So I think this should be fixed!

Before this patch landed, the branches statuses are:

v1.4: the music open activity will be closed after the user pressed the home button, which means the open activity is unable to play music in background.

v2.0: (before patch landed) the music open activity will be kept in the background after the user pressed the home button, which means the open activity is able to play music in background.

master: (after patch landed) the music open activity will be closed after the user press the home button, which means the open activity is unable to play music in background.

Apparently, the music open activity shouldn't play music in the background since it's an existing behaviour from v1.4, on v2.0 it's a regression for sure because the behaviour is changed. George's patch has solved that regression, and brought back what we had in v1.4.

And if you want the music open activity to be able to play music in the background, then it's a feature request which we had accidentally enabled it(regression), we need the ux approval to change this, make sense?

Comment 52

[Luke Chang [:lchang] (inactive)]

I'm investigating bug 1084247 and found that one of those issues can be fixed by this bug. However, I also found that this patch doesn't work without bug 1032068 on v2.0 branch. So, I set the dependency here and will nominate bug 1032068 as 2.0? later.

Comment 53

[Safwan Rahman (:safwan)]

(In reply to Dominic Kuo [:dkuo] from comment #51)
> 
> Before this patch landed, the branches statuses are:
> 
> v1.4: the music open activity will be closed after the user pressed the home
> button, which means the open activity is unable to play music in background.
> 
> v2.0: (before patch landed) the music open activity will be kept in the
> background after the user pressed the home button, which means the open
> activity is able to play music in background.
> 
> master: (after patch landed) the music open activity will be closed after
> the user press the home button, which means the open activity is unable to
> play music in background.
> 
> Apparently, the music open activity shouldn't play music in the background
> since it's an existing behaviour from v1.4, on v2.0 it's a regression for
> sure because the behaviour is changed. George's patch has solved that
> regression, and brought back what we had in v1.4.
> 
> And if you want the music open activity to be able to play music in the
> background, then it's a feature request which we had accidentally enabled
> it(regression), we need the ux approval to change this, make sense?

Thanks for providing the branch status. But I think its not wise to compare anything with 1.4 because V1.4 has been sailed a long long ago and there is major UX/UI change in 2.0. So we need to check what make sense in 2.0. Can you please provide me any build ID of 2.0, where its working as you expected? The structure may be properly changed in 2.0, so I think the feature which I expected might be designed by UI/UX team in 2.0! :) SO if you can provide me any build ID of 2.0 where this feature is not having, so that time we can regard it as regression. but till that time, I dont think so.

And regarding this bug, I believe it should fix only the issue described in comment 40 or comment 0. If this bug needed to be fixed by implementing that feature(turn off audio after tapping home button), I think another bug should be filled for implementing that feature. and which will block the issue.

I believe if this bug need to be regarded as fixed the following statement should be mentioned, 
# The patch should work like that it will not close the music after tapping the home button
or
# Another bug should be filled about closing "bluetooth transferred music" after tapping home button. And after that bug has been fixed, this bug should be regarded as fixed. I think it will keep track of everything we change in Gaia.

Comment 54

[Safwan Rahman (:safwan)]

Fabrice, can you please check the comment 46, comment 47 and comment 53

Comment 55

[bhavana bajaj [:bajaj]]

(In reply to Safwan Rahman from comment #53)
> (In reply to Dominic Kuo [:dkuo] from comment #51)
> > 
> > Before this patch landed, the branches statuses are:
> > 
> > v1.4: the music open activity will be closed after the user pressed the home
> > button, which means the open activity is unable to play music in background.
> > 
> > v2.0: (before patch landed) the music open activity will be kept in the
> > background after the user pressed the home button, which means the open
> > activity is able to play music in background.
> > 
> > master: (after patch landed) the music open activity will be closed after
> > the user press the home button, which means the open activity is unable to
> > play music in background.
> > 
> > Apparently, the music open activity shouldn't play music in the background
> > since it's an existing behaviour from v1.4, on v2.0 it's a regression for
> > sure because the behaviour is changed. George's patch has solved that
> > regression, and brought back what we had in v1.4.
> > 
> > And if you want the music open activity to be able to play music in the
> > background, then it's a feature request which we had accidentally enabled
> > it(regression), we need the ux approval to change this, make sense?
> 
> Thanks for providing the branch status. But I think its not wise to compare
> anything with 1.4 because V1.4 has been sailed a long long ago and there is
> major UX/UI change in 2.0. So we need to check what make sense in 2.0. Can
> you please provide me any build ID of 2.0, where its working as you
> expected? The structure may be properly changed in 2.0, so I think the
> feature which I expected might be designed by UI/UX team in 2.0! :) SO if
> you can provide me any build ID of 2.0 where this feature is not having, so
> that time we can regard it as regression. but till that time, I dont think
> so.
> 
> And regarding this bug, I believe it should fix only the issue described in
> comment 40 or comment 0. If this bug needed to be fixed by implementing that
> feature(turn off audio after tapping home button), I think another bug
> should be filled for implementing that feature. and which will block the
> issue.
> 
> I believe if this bug need to be regarded as fixed the following statement
> should be mentioned, 
> # The patch should work like that it will not close the music after tapping
> the home button
> or
> # Another bug should be filled about closing "bluetooth transferred music"
> after tapping home button. And after that bug has been fixed, this bug
> should be regarded as fixed. I think it will keep track of everything we
> change in Gaia.

This bug is getting way too confusing and I think UX team is the best to explain the correct behavior here comparing the 1.4/2.0 usecase.

Additionally, I think we should uplift the patch here as it fixes the report in comment #0 and file a new bug per UX feedback as needed.

Comment 56

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/3fe1bf1ed134a17581866e526ba75e7ed2aee77e

Comment 57

[Dominic Kuo [:dkuo]]

(In reply to bhavana bajaj [:bajaj] from comment #55)
> This bug is getting way too confusing and I think UX team is the best to
> explain the correct behavior here comparing the 1.4/2.0 usecase.
> 
> Additionally, I think we should uplift the patch here as it fixes the report
> in comment #0 and file a new bug per UX feedback as needed.

Agree, let's move the ux discussion(also the needinfo) to bug 1086280 and leave this one fixed, thanks.

Comment 58

[bhavana bajaj [:bajaj]]

Comment on attachment 8507741 [details] [review]
PR to 2.0

Requesting QA verification once this lands on 2.0

Comment 59

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/7e66c5769d5d6ac93dd6d76f7a18e49175eb00cc

Comment 60

[Yeojin Chung [:YeojinC]]

This bug is verified fixed on Flame 2.0.

Result: After following STRs from Comment 0, the music plays properly.

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141028000202
Gaia: 5e532a84e762b1bb6231756182cf1465671a061e
Gecko: 124f0bed1700
Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
==================================================

This issue still reproduces on Flame 2.1 and 2.2.

Result: After following STRs from Comment 0, the music becomes unresponsive. 
(However, the music control is responsive. User can start the music by pressing pause/play button)

Flame 2.2

Device: Flame Master (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141028040202
Gaia: 6a7fb482a03c5083ef79b41e7b0dfab27527cd04
Gecko: a255a234946e
Version: 36.0a1 (Master)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
  
Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141028001203
Gaia: a0174f7166745256aaca1cb3aa9f894033fbffa6
Gecko: 43bda3541f6b
Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 61

[Kai-Zhen Li [:seinlin][:kli]]

v2.0m: https://github.com/mozilla-b2g/gaia/commit/7e66c5769d5d6ac93dd6d76f7a18e49175eb00cc

Comment 62

[Lance（leave from Mozilla）]

We have verified this issue on Woodduck 2.0, Flame 2.1 and 2.2, but this issue stille exist in Flame 2.2. Woodduck 2.0 and Flame 2.1 does not exist it. We have uploaded new logcat and video to Bugzilla.
Found time:11:04
Fail rate: 2/2
See attachment:1104.mp4 and logcat_1104.txt

Step:
1. Open music->play any song->receive a file via Bluetooth->wait for download complete->drag notification->Play downloaded file.

Actual results:
Music player hangs , user cannot access any player controls.

Expected results:
Music player should play the received file properly.

Woodduck version:
Gaia-Rev        3a98f1287fa7b604891220ba5d86982ae8f9971e
Gecko-Rev       03d3ab62d5b07b915434f2d1d68495ad5915ecd2
Build-ID        20141120103003
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2
FW-Incremental  1416391964
FW-Date         Wed Nov 19 18:12:54 CST 2014

Flame 2.1 version:
Gaia-Rev        f8d3bf44029e0afc0124600a4bb34dba8fc1ad21
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-2g34_v2_1/rev/f70a67a7f846
Build-ID        20141120001207
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141120.034911
FW-Date         Thu Nov 20 03:49:22 EST 2014
Bootloader      L1TC00011880

Flame 2.2 version:
Gaia-Rev        1abe09b4925547699dfdb2d358aed019137c3aa6
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/6ce1b906c690
Build-ID        20141120040205
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141120.073331
FW-Date         Thu Nov 20 07:33:41 EST 2014
Bootloader      L1TC00011880

Comment 63

[Lance（leave from Mozilla）]

Attachment: logcat_1104.txt

Comment 64

[Lance（leave from Mozilla）]

Attachment: 1104.MP4

Comment 65

[William Hsu [:whsu]]

Hi, folks,

I think we can file a follow up instead of keeping in pending status.
Bug 1113000. FYI.

Have a nice day! :)