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

VERIFIED FIXED in Firefox OS v2.0

Status

VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: ranjith253, Assigned: gduan, NeedInfo)

Tracking

unspecified
2.1 S7 (24Oct)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 verified, b2g-v2.2 fixed)

Details

(Whiteboard: [LibGLA,TD102026,QE2,B])

Attachments

(6 attachments)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
Whiteboard: [LibGLA,TD102026,QE2,B]
(Reporter)

Comment 1

4 years ago
Hi wayne,

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

Thanks.
Flags: needinfo?(wchang)
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.
Flags: needinfo?(ranjith253)
[Blocking Requested - why for this release]:
partner requested as blocker.
blocking-b2g: --- → 2.0?
(Reporter)

Comment 4

4 years ago
(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] 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.
(Reporter)

Comment 5

4 years ago
Created attachment 8500884 [details]
issuescreenshot
Flags: needinfo?(ranjith253)

Comment 6

4 years ago
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.
Component: Gaia::Music → Gaia::System::Window Mgmt
Hi Alive, per comment 6, could you please provide your comments and feedback ? 
Thank you very much !
Flags: needinfo?(alive)
qawanted for master
Flags: needinfo?(alive)
Keywords: qawanted
Hi star, 
Could you please kindly look into this issue ? Will it be related to bug1003025/ bug1062144 ?
Thank you very much !
Flags: needinfo?(scheng)

Comment 10

4 years ago
(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] 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!
Flags: needinfo?(scheng)
Summary: [System][Music] Player is hanged for multiple Bluetooth transfer. → 1st inline activity is not killed before the second inline activity comes.
It can be reproduced in latest maser V2.2

Environmental Variables:
Device: Keon V2.2
BuildID: 20141008012326
Gaia: 68b8bc9
Gecko: 652c5d4
Version: 35.0a1
Status: UNCONFIRMED → NEW
status-b2g-v2.2: --- → affected
Ever confirmed: true
QA Contact: safwan.rahman15
(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
status-b2g-v2.0: --- → affected
Keywords: qawanted
looks like rachelle has taken care here.
Flags: needinfo?(wchang)
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!
Flags: needinfo?(dkuo)

Comment 15

4 years ago
(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] 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!
Flags: needinfo?(dkuo) → needinfo?(alive)
Transfer to George.
Flags: needinfo?(alive) → needinfo?(gduan)
Assignee: nobody → gduan
Flags: needinfo?(gduan)
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.
Flags: needinfo?(safwan.rahman15)
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
Flags: needinfo?(safwan.rahman15)
Triage to set it to 2.0+ ; 100% reproduce rate,reproducible on master, besides partner requested this as blocker.
blocking-b2g: 2.0? → 2.0+
Created attachment 8506001 [details] [review]
PR to master

Hi Alive,
please kindly check my proposal for this bug. 
Thanks.
Attachment #8506001 - Flags: review?(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?)
Attachment #8506001 - Flags: review?(alive)
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.
Flags: needinfo?(safwan.rahman15)
Flags: needinfo?(ranjith253)
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
Flags: needinfo?(safwan.rahman15) → needinfo?(gduan)
I just tested today's central build and found out that I can reproduce it with mp3 file but cannot with ogg file.
Flags: needinfo?(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 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?
Attachment #8506001 - Flags: feedback?(dkuo)
I also modify part of app_window.js for comment 22.

Comment 28

4 years ago
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 :)
Attachment #8506001 - Flags: feedback?(dkuo) → feedback+
Comment on attachment 8506001 [details] [review]
PR to master

Hi Alive,
could you kindly review it? I think the reason is as comment 25.
Attachment #8506001 - Flags: review?(alive)
Comment on attachment 8506001 [details] [review]
PR to master

r+ with nit(and test wanted with it) thanks!
Attachment #8506001 - Flags: review?(alive) → review+
status-b2g-v2.1: --- → affected
Created attachment 8507740 [details] [review]
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]:
Attachment #8507740 - Flags: approval-gaia-v2.1?
Created attachment 8507741 [details] [review]
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]:
Attachment #8507741 - Flags: approval-gaia-v2.0?
(Reporter)

Updated

4 years ago
Flags: needinfo?(ranjith253)
(Reporter)

Comment 34

4 years ago
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.
Flags: needinfo?(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.
Flags: needinfo?(gduan)
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?
Flags: needinfo?(ranjith253)
Flags: needinfo?(gduan)
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
Keywords: regressionwindow-wanted
(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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
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?
Flags: needinfo?(gduan)
Flags: needinfo?(dkuo)
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
Flags: needinfo?(safwan.rahman15)
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
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?
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
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
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?
Flags: needinfo?(safwan.rahman15) → needinfo?(jmercado)

Comment 44

4 years ago
Let's followup in bug 1085380.

Updated

4 years ago
Flags: needinfo?(dkuo)
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 :)
Keywords: verifyme
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
Flags: needinfo?(gduan)
I am reopening this bug as its depends on another bug.
Status: RESOLVED → REOPENED
Depends on: 1086280
Resolution: FIXED → ---
See Also: → bug 1085380
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
Flags: needinfo?(jmercado)

Comment 49

4 years ago
(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)
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Flags: needinfo?(gduan)
Resolution: --- → FIXED
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!
Flags: needinfo?(dkuo)

Comment 51

4 years ago
(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?
Flags: needinfo?(dkuo)
See Also: → bug 1084247
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.
Depends on: 1032068
(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.
Flags: needinfo?(dkuo)
status-b2g-v2.2: affected → fixed
Target Milestone: --- → 2.1 S7 (24Oct)
Attachment #8507740 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Fabrice, can you please check the comment 46, comment 47 and comment 53
Flags: needinfo?(fabrice)
(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.

Updated

4 years ago
Flags: needinfo?(jsavory)

Comment 57

4 years ago
(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.
Flags: needinfo?(dkuo)

Updated

4 years ago
Flags: needinfo?(jsavory)
Comment on attachment 8507741 [details] [review]
PR to 2.0

Requesting QA verification once this lands on 2.0
Attachment #8507741 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
status-b2g-v2.0: affected → fixed
Flags: needinfo?(fabrice)
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
status-b2g-v2.0: fixed → verified
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
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
Flags: needinfo?(jocheng)
status-b2g-v2.0M: fixed → verified
status-b2g-v2.1: fixed → verified
Created attachment 8526515 [details]
logcat_1104.txt

Updated

4 years ago
Flags: needinfo?(jocheng) → needinfo?(hlu)
Flags: needinfo?(hlu)

Updated

4 years ago
Blocks: 1113000

Comment 65

4 years ago
Hi, folks,

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

Have a nice day! :)
No longer blocks: 1113000
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.