Closed Bug 1116732 Opened 9 years ago Closed 9 years ago

[Flame][Music]We cannot play music again after we share currently playing song as ringtone.

Categories

(Firefox OS Graveyard :: Gaia::Music, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 unaffected, b2g-v2.1 unaffected, b2g-v2.1S unaffected, b2g-v2.2 affected, b2g-master unaffected)

RESOLVED INCOMPLETE
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- unaffected
b2g-v2.1S --- unaffected
b2g-v2.2 --- affected
b2g-master --- unaffected

People

(Reporter: huayu.li, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: eta target 4/17)

Attachments

(7 files)

Attached file logcat2.txt
[1.Description]:
[Flame][v2.1&2.2][Music]We cannot play music agian after we share currently playing song as  ringtone.
Occurence time:4:08
see attachments:logcat2.txt,1.3gp

[2.Testing Steps]: 
1.Launch music.
2.Tap one song to play.
3.Tap share button -> ringtone -> save.
4.Back to music list view and tap this song agian.
5.Back to music list view and try to play other songs.

[3.Expected Result]: 
4&5.The song you selected should be played from start.

[4.Actual Result]: 
4&5. Playing paused and you cannot play the song you selected in step 4&5.

[5.Reproduction build]: 
Flame 2.1 build:
Gaia-Rev        73be51f998031f06db0cd660c0e388fa621c9f4c
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ea426e47bfc4
Build-ID        20141230001256
Version         34.0

Flame 2.2 build:
Gaia-Rev        322ef5116a5827a30c9a3cd9b842449a9c66a5b3
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/67872ce17918
Build-ID        20141230010205
Version         37.0a1

[6.Reproduction Frequency]: 
Always Recurrence,3/3
TCID: Free Test
Attached video 1.3gp
This works fine for me on the latest 2.2 build on a Flame.
verify with yesterday's v2.2 gaia/gecko, still has this problem
Gaia-Rev        c2bf20d23851d5fda9f8f0ef0267db5f49152376
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/636498d041b5
Build-ID        20150104160203
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150104.193130
FW-Date         Sun Jan  4 19:31:41 EST 2015
Bootloader      L1TC10011880

Hi Dominic, could you help with this, thanks.
Following steps from comment 0 can 100% reproduce this issue.
Flags: needinfo?(dkuo)
Sorry for the late reply but I was able to reproduce it on v2.2 but v2.1, if so, then this should be a gecko issue and can we request for regression? thanks.
Flags: needinfo?(dkuo) → needinfo?(mlien)
Flags: needinfo?(mlien)
The latest v2.1 seems cannot reproduce this, and I found bug 1101448 should be a same issue.
QA Contact: ktucker
This issue does not occur on the latest Flame 3.0, Flame 2.2, Flame 2.1 and Flame 2.0

The songs selected are not paused and will play as expected after following the steps in Comment 0. 

Environmental Variables:
Device: Flame 3.0
Build ID: 20150202010229
Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a
Gecko: 940118b1adcd
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Environmental Variables:
Device: Flame 2.2 (Full Flash)(319mb)(KK)
BuildID: 20150202002507
Gaia: d6141fa3208f224393269e17c39d1fe53b7e6a05
Gecko: be206fa2fb60
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Environmental Variables:
Device: Flame 2.1 (Full Flash)(319mb)(KK)
BuildID: 20150202001432
Gaia: 63f291df9b9ad8498fb8fc7fb8bf070524406a5c
Gecko: 70b8982a523d
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0 (Full Flash)(319mb)(KK)
BuildID: 20150202000205
Gaia: 2989f2b2bd12fcc0e9c017d2db766e76a55873b8
Gecko: b961877cacba
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Leaving regressionwindow-wanted for someone else to try.
Investigating this further because somehow I just reproduced this on 2.2 using the duplicate bug's steps.
I figured out why I was unable to reproduce this issue. The phone must fall asleep first before attempting the steps in Comment 0. 

This issue occurs on the Flame 3.0 and Flame 2.2

The song does not play and will be stuck in a pause state. 

Environmental Variables:
Device: Flame 3.0
Build ID: 20150202010229
Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a
Gecko: 940118b1adcd
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Environmental Variables:
Device: Flame 2.2 (Full Flash)(319mb)(KK)
BuildID: 20150202002507
Gaia: d6141fa3208f224393269e17c39d1fe53b7e6a05
Gecko: be206fa2fb60
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

-------------------------------------------------------------------

This issue does not occur on the Flame 2.1 and Flame 2.0

The song does not gets stuck in a paused state and plays at expected. 

Environmental Variables:
Device: Flame 2.1 (Full Flash)(319mb)(KK)
BuildID: 20150202001432
Gaia: 63f291df9b9ad8498fb8fc7fb8bf070524406a5c
Gecko: 70b8982a523d
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0 (Full Flash)(319mb)(KK)
BuildID: 20150202000205
Gaia: 2989f2b2bd12fcc0e9c017d2db766e76a55873b8
Gecko: b961877cacba
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

I will now get a regression window for this issue.
Bug 1076975 seems to be the cause for this issue.

Mozilla-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141020173635
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: 5515fa5ba20d
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141020174936
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: 33f348ff0417
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: 33f348ff0417

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: dc496d04907dd314f9736ff78bab3bd27156f79a
Gecko: 5515fa5ba20d

Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5515fa5ba20d&tochange=33f348ff0417
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Ben can you take a look here please? Looks like this issue was introduced by the patch for bug 1076975.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(bent.mozilla)
Can someone please attach an updated logcat (preferably from a DEBUG build) that reproduces the problem?
Flags: needinfo?(bent.mozilla)
Nominating for 2.2, it's a functional regression of a core feature.

Also adding qawanted to get the logcat on an engineering build with the needed prefs enabled.
blocking-b2g: --- → 2.2?
Keywords: qawanted
Uploaded logcat from engineering build.

Note that in order to reproduce the bug, the device must have fallen asleep at least once before attempting STR.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
02-10 18:36:33.394  1671  1671 W Ringtones: [JavaScript Warning: "An IndexedDB transaction that was not yet complete has been aborted due to page navigation." {file: "app://ringtones.gaiamobile.org/gaia_build_defer_share.js" line: 362}]

Hm, this might be the problem...

https://mxr.mozilla.org/gaia/source/apps/ringtones/js/custom_ringtones.js#262

We're not waiting for the transaction to commit before resolving the promise. If we resolve too soon, and the app finishes its activity and closes the window that initiated the database request, then the transaction will be rolled back.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Blocking Reason: Basic scenario broken.
blocking-b2g: 2.2? → 2.2+
Assignee: nobody → squibblyflabbetydoo
This issue still exist on  Flame 2.2 ,and NOT exist on Flame Master

FLame2.2:
Build ID               20150301002505
Gaia Revision          77609916ca5ab721150fab2b7bc5c37f43ee3a5a
Gaia Date              2015-02-27 16:35:06
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/27ab8aa34201
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150301.040042
Firmware Date          Sun Mar  1 04:00:53 EST 2015
Bootloader             L1TC000118D0

Flame 3.0:
Build ID               20150301010223
Gaia Revision          f34ce82a840ad3c0aed3bfff18517b3f6a0eb37f
Gaia Date              2015-02-27 15:48:31
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/eea6188b9b05
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150301.045059
Firmware Date          Sun Mar  1 04:51:10 EST 2015
Bootloader             L1TC00011
refer to video and logcat
Attached file logcat(5).txt
Happen time 5:10
Attached video VIDEO0286_Compress.MP4
Happen time 5:10
Hi Elie, could you help to give the build information with v2.1S from comment 17?
I think you already verified this issue on v2.1S, right?
Flags: needinfo?(zikui.yang)
Jim,

Any update on this?

Thanks
Hema
Flags: needinfo?(squibblyflabbetydoo)
Not yet, no. I have some difficulty believing that comment 15 is the source of the problem since, worst-case scenario, the transaction gets rolled back and the ringtone isn't correctly added (this should probably be fixed anyway, though). I really can't see why that would break a non-indexedDB part of a completely separate app. The fact that I can't reproduce this bug in the first place makes it a lot harder to fix.
Flags: needinfo?(squibblyflabbetydoo)
Ok, I managed to reproduce this somehow after updating Gaia but not Gecko, so I'll stick on this version for a while since it seems like this goes away on an up-to-date build. However, as I suspected, comment 15 has no bearing on this whatsoever. I'll file a new bug for it though, since it'd be nice to fix.
I've narrowed the issue down to a single line, where we're setting a mozSettings entry to a file-backed Blob. Removing that line or using a non-file-backed Blob makes everything happy. Therefore, this seems like a mozSettings bug.

That said, I've never been quite sure of the semantics of putting file-backed Blobs in mozSettings. What happens if the file is removed, e.g. if it was on an SD card that gets taken out?
Flags: needinfo?(bent.mozilla)
(In reply to Mike Lien[:mlien] from comment #20)
> Hi Elie, could you help to give the build information with v2.1S from
> comment 17?
> I think you already verified this issue on v2.1S, right?

Test on Dolpin 2.1S(512),this issue does not exist,build imformation as follow:
Gaia-Rev        a43d64ae01ef108aa4dcc971c770fecd8416a764
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2437280c634f
Build-ID        20150301161204
Version         34.0
Device-Name     scx15_sp7715ea
FW-Release      4.4.2
FW-Incremental  122
FW-Date         Thu Feb  5 12:42:58 CST 2015
Flags: needinfo?(zikui.yang) → needinfo?(mlien)
Thanks Elie, let's wait developer's patch
Flags: needinfo?(mlien)
Ok, I was wrong, even non-file backed Blobs cause this issue, but the Blob has to be a valid audio file. I'm not sure who to redirect this bug to; maybe someone on the System app?
Could we get a regression window for when this started working on master again? Maybe that would help us narrow down what the problem is. It's possible we just need to uplift a particular patch to 2.2.
This issue still occurs on latest Flame 3.0 master. The check on comment 17 is incorrect. 

I'm gonna re-write the STR so we have as little discrepancies in the environment as possible.

Prerequisites:
Have 8 mp3 files on the external SD card of the device, songs are placed under root directory of the card (not inside any folder)

STR:
1) Full flash the phone to any build from affected branch
2) Progress past FTU without changing anything
3) Once on Homescreen, let it sit so it falls asleep
4) Wake up the device, unlock, and open Music app
5) Tap on a song to play
6) Tap on the album art to invoke additional UI > tap on share button > Ringtones > Save
7) Return to Music main page, and tap to play the same song again

Observed behavior: The song will not play and progress bar is stuck at previous position.

Device: Flame 3.0
BuildID: 20150303010233
Gaia: c8ed1085a67490a1ecd7f275e5de9487e1b93b1d
Gecko: 0b3c520002ad
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: ktucker
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
timdream: Do you have any idea what might be happening here? It seems that this bug occurs when the mozSetting "dialer.ringtone" is set (to a valid audio Blob). I'm guessing this has something to do with the system app listening to changes to that mozSetting key...
Flags: needinfo?(bent.mozilla) → needinfo?(timdream)
I will be taking PTO starting tomorrow and be back on Wed ... you may want to find someone else for your question first or try to |grep| the code.
Etienne: Maybe you know about this? See comment 30. I think this code might be causing us problems:

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/dialer_agent.js#L81-L90
Flags: needinfo?(timdream) → needinfo?(etienne)
(In reply to Jim Porter (:squib) from comment #32)
> Etienne: Maybe you know about this? See comment 30. I think this code might
> be causing us problems:
> 
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/dialer_agent.
> js#L81-L90

I definitely know about this code, but I can't see anything "wrong" with it :/
Good thing is, it's easy to reproduce the bug so maybe El Doctor can help us.

Are we doing anything wrong with the mozSettings API between [1] and [2]?

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/dialer_agent.js#L81-L90
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/ringtones/js/system_tones.js#L81-101
Flags: needinfo?(etienne)
Flags: needinfo?(lissyx+mozillians)
Can you reproduce with all mozSettings debug and verbose prefs enabled, reproduce and record logcat?

https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js?from=all.js&case=true#4474
Flags: needinfo?(lissyx+mozillians)
Can't reproduce the bug with all the debug flags on.
(In reply to Etienne Segonzac (:etienne) from comment #33)
> (In reply to Jim Porter (:squib) from comment #32)
> > Etienne: Maybe you know about this? See comment 30. I think this code might
> > be causing us problems:
> > 
> > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/dialer_agent.
> > js#L81-L90
> 
> I definitely know about this code, but I can't see anything "wrong" with it
> :/
> Good thing is, it's easy to reproduce the bug so maybe El Doctor can help us.
> 
> Are we doing anything wrong with the mozSettings API between [1] and [2]?
> 
> [1]
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/dialer_agent.
> js#L81-L90
> [2]
> https://github.com/mozilla-b2g/gaia/blob/master/apps/ringtones/js/
> system_tones.js#L81-101

I cannot see anything obviously wrong there. Since this has been first reported on 2.1, why don't we have a regression window on this ?

In comment 11, bug 1076975 was suspected ? Can we assert whether this is the root cause or just that the fix is exposing something bad in the mozSettings API ?

There was quite a lot of changes on this side, so it may have broken.
Flags: needinfo?(pbylenga)
Adding regressionwindow to perform a bisection to identify if bug 1076975 is the cause.

Also as a fail safe let's recheck 2.0.

Raising urgency to prioritize qa.

NI on No-Jun and Naoki to assist if they are able.
Flags: needinfo?(pbylenga)
Flags: needinfo?(npark)
Flags: needinfo?(nhirata.bugzilla)
This issue does NOT occur on the latest 2.0 tinderbox build 0/5 attempts.

Environmental Variables:
Device: Flame 2.0
BuildID: 20150306065845
Gaia: 8463d1c9142f32c8ea175048dac52e41620443ce
Gecko: 3aed59876545
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Jayme, not that I want to blame or induce anything, but can we be rock solid 100% sure on this ? And not like previous comment that stated it was NOT reproducing on master when it was indeed :)
Flags: needinfo?(jmercado)
I can confirm that this issue does not reproduce on 2.0. Repro rate is 0 out of 5 on 2.0.

Device: Flame 2.0 (full flash, nightly user, 319MB mem)
BuildID: 20150309000203
Gaia: 8463d1c9142f32c8ea175048dac52e41620443ce
Gecko: 9399de0723a0
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(jmercado)
Hi Hema, we tried to test on the backout build of 2.2 (See Comment 10) but we had some difficulty building it due to the dependency errors.  Could someone in the Music team be able to test out the build to see whether the fix for Bug 1076975 is indeed the cause for this?
Flags: needinfo?(npark) → needinfo?(hkoka)
Hub,

Could you please help with this?

Thanks much!
Hema
Flags: needinfo?(hkoka) → needinfo?(hub)
Flags: needinfo?(nhirata.bugzilla)
I can reproduce.

It doesn't seem to be trivial to revert. Looking further if I can do it.
We can't just be reverting the patch. Too many changes. We'd better off fix the bug. Since there is a bug - I can reproduce.
Flags: needinfo?(hub)
Alexandre/Etienne,

Who can help fix this issue? Reverting the patch that is being suspected does not seem to be an trivial one based on previous trials from Hub and QA folks. 

Thanks
Hema
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(etienne)
Assignee: squibblyflabbetydoo → nobody
(In reply to Hema Koka [:hema] from comment #45)
> Alexandre/Etienne,
> 
> Who can help fix this issue? Reverting the patch that is being suspected
> does not seem to be an trivial one based on previous trials from Hub and QA
> folks. 
> 
> Thanks
> Hema

Why not taking Gecko/Gaia just prior to this patch, assert it works correctly, then include the suspected patch, assert it's broken ? If you can't revert, just don't revert, take your time machine.
Flags: needinfo?(lissyx+mozillians)
If we're talking about reverting bug 1076975, we can't do that, since it's just swapping one broken thing for another. Given that bug 994190* was never backed out, despite having broken things for months, I don't think "back this out" is a workable solution.

Overall, the indexedDB-on-PBackground changes have not been a particularly good experience for Firefox OS, especially the Ringtones app.

* Probably the original source of the issue if bug 1076975 is indeed part of the problem.
(In reply to Jim Porter (:squib) from comment #47)
> If we're talking about reverting bug 1076975, we can't do that, since it's
> just swapping one broken thing for another. Given that bug 994190* was never
> backed out, despite having broken things for months, I don't think "back
> this out" is a workable solution.
> 
> Overall, the indexedDB-on-PBackground changes have not been a particularly
> good experience for Firefox OS, especially the Ringtones app.
> 
> * Probably the original source of the issue if bug 1076975 is indeed part of
> the problem.

Please stick to reading what I'm saying. If we suspect bug 1076975 to be the cause of this regression, let's take the sources just before it, check that the bug do not reproduces, then take the patch, and test that the bug does reproduce.

The current status is, from my point of view: a bunch of people saying "maybe, dunno", some point "THIS" some other "THAT". But we still have not asserted the original suspects.
Re-reading myself I feel the previous comment might feel rude, when it's not the case. So let me rephrase it: I'm not asking for a backout, I just want that we get a clear picture of what triggered this. Bug 1076975 is one potential suspect, and during the same time frame we did changes to the mozSettings API. Although I see nothing obviously supposed to be breaking this kind of stuff, I want to be sure whether bug 1076975 triggered or it is something else and start investigating in the Settings API.

To make it worse, I have not been able to properly reproduce this.
spoke to no-jun offline, he is going to help test to isolate if Bug 1076975 is the cause. leaving an NI on him for results from the test
Flags: needinfo?(etienne) → needinfo?(npark)
Piwei, please recheck this window as well.
Flags: needinfo?(pcheng)
We've confirmed the window is correct. The bug reproduces 0 out of 10 attempts on last working build, and 10 out of 10 attempts on first broken build.

I have made another video demonstrating this bug from FTE to bug repro'ing. We've shortened the step from requiring the phone to fall asleep to simply locking and unlocking the phone on Music app. Hopefully this leaves no room for doubts on how to reproduce this bug.

Video: https://www.youtube.com/watch?v=_ixiiVQv3L4

No Jun is actively working on bisecting further to pinpoint which bug in the pushlog caused the issue. He should be able to give us the absolute cause soon.
Flags: needinfo?(pcheng)
    > Why not taking Gecko/Gaia just prior to this patch, assert it works
    > correctly, then include the suspected patch, assert it's broken ? If you
    > can't revert, just don't revert, take your time machine.

    So what happens when we're finding the regression range (shown in Comment 10) is that we bisect the nightly builds until we find the first breaking build in nightly.  Then to find more precise range, we continue the bisection in mozilla-inbound flame-kk build.  After that, we swap gaia and gecko between the last passing and first failing builds to identify whether it is gaia or gecko issue. Usually this gives the range that is granular enough to provide clues to the possible cause.  The regression range in Comment 10 was obtained that way. And it is just rechecked using the mozilla-inbound tinderbox builds, since qanalysts have local copy of the mozilla-inbound builds that goes back many months.  Since they do full flash of the build, it reflects the exact build that was released at the time.  

    I initially thought :gerard-majax found the regression range to be off for some reason, but after reading Comment 46, perhaps it was because we didn't communicate how we find the regression range.  KTucker just confirmed that the initial regression range reported in Comment 10 is still reproducible, and he will also post the exact steps to reproduce it. between the last failing (Bug 1076975) and first passing (Bug 1084193) gecko in moz-inbound builds, there is only one gecko commit, which is 

    commit 10c76b1dc35f4d33c8b0ba673afe723ad180145d
    Author: Ben Turner <bent.mozilla@gmail.com>
    Date:   Mon Oct 20 17:48:56 2014 -0700

       Bug 1085381 - Remove bad assertion, r=khuey.

    This seems to be a quite unlikely suspect, but just to be safe, I resetted gecko to this commit and tested on my phone, and I was not able to repro the bug. So we're pretty confident that the culprit is Bug 1076975
Flags: needinfo?(npark)
Hi Ben, do you mind to take a look as Comment 53 mentioned?
Flags: needinfo?(bent.mozilla)
STR:

Important note that this issue is only reproducible when the "Ringtone saved successfully" banner appears at the top of the screen. 

There is another issue with ringtones not saving properly which blocks the user from reproducing this issue on the "First Broken Build" in the regression window.

1. Factory reset the phone.
2. Quickly skip through the FTE.
3. Open the music app.
4. While the music app is loading the songs, manually lock and unlock the Flame device.
5. Tap on the song in the upper right corner of the grid view to play it and then quickly tap the "Share" button.
6. Tap "Ringtones" and then "Save". If the banner appears at the top of the screen then continue to step 7 otherwise, you will have to factory reset the phone and try steps 1 through 6 again.
7. Quickly tap the back arrow while the banner is at the top of the screen and tap on the same song again that was used in Step 5.
8. Tap the back arrow again and quickly tap on a different song in the grid view to play it. 

Actual:
The song does not start from the beginning and is stuck in a paused state.

Expected:
The song plays from the beginning without issue.

On the latest builds this is much easier to reproduce because the ringtones are always saved successfully.
Here is the video of me reproducing this issue on the First Broken Build in the regression window.

http://youtu.be/8E4MASsVVoU
Flags: needinfo?(bent.mozilla) → needinfo?(dkuo)
Some more questions, as I don't see obvious answers in this thread:

* do we reproduce if, instead of sharing to ringtones, we share to another application ? (eg: SMS, email...)
* do we reproduce if we don't lock the phone?

Thanks
Flags: needinfo?(ktucker)
This issue is much easier to reproduce on the latest builds. The user does not have to lock the device or tap the share button at all. The STR is not as involved on the latest builds but you still have to follow the steps in Comment 55 to test the regression window that i posted.

STR:

1. Factory reset the dut.
2. Skip through the FTE and open the music app.
3. Tap on a song to play it.
4. Tap the "Back" arrow.
5. Tap on the same song again.
6. Tap the "Back" arrow and tap on a different song to play it.

Actual:
The song will be in a paused state and not play.

Environmental Variables:
Device: Flame Master (KK, 319mb, full flash)
Build ID: 20150323010204
Gaia: 9b6f3024e4d0e62dd057231f4b14abe1782932ab
Gecko: e730012260a4
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Flags: needinfo?(ktucker)
I think this should direct to Ben not Dominic.
Flags: needinfo?(dkuo) → needinfo?(bent.mozilla)
Andrew,

Who can help in Ben's absence?

Thanks
Hema
Flags: needinfo?(overholt)
Update: Andrew Overholt is working with Ben to see when we can get this landed. 

Andrew: Please move to the right component.

Thanks
Hema
Adding eta to 4/17 based on IRC conversation with overholt. Bent will be taking this up.

Thanks
Hema
Whiteboard: eta target 4/17
(In reply to Hema Koka [:hema] from comment #62)
> Adding eta to 4/17 based on IRC conversation with overholt. Bent will be
> taking this up.

In the meantime if anyone can figure out a test for this that would be very helpful. The tree is still green as far as I can tell?
Flags: needinfo?(bent.mozilla)
Flags: needinfo?(overholt)
(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #63)
> (In reply to Hema Koka [:hema] from comment #62)
> > Adding eta to 4/17 based on IRC conversation with overholt. Bent will be
> > taking this up.
> 
> In the meantime if anyone can figure out a test for this that would be very
> helpful. The tree is still green as far as I can tell?

Actually you can also request manual testing for the fix with the patch, you can either needinfo me or :ktucker
(In reply to No-Jun Park [:njpark] from comment #64)
> Actually you can also request manual testing for the fix with the patch, you
> can either needinfo me or :ktucker

Thanks, that's good to know. But I'm more interested in automated testing to prevent things like this from breaking in the future.
(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #65)
> (In reply to No-Jun Park [:njpark] from comment #64)
> > Actually you can also request manual testing for the fix with the patch, you
> > can either needinfo me or :ktucker
> 
> Thanks, that's good to know. But I'm more interested in automated testing to
> prevent things like this from breaking in the future.

Geo should be able to provide more accurate answer for this one, but to my knowledge there is currently no automated test that can check whether the music is playing correctly.  (we can check it is playing per se though)
Flags: needinfo?(gmealer)
(In reply to No-Jun Park [:njpark] from comment #66)
> (In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #65)
> > (In reply to No-Jun Park [:njpark] from comment #64)
> > > Actually you can also request manual testing for the fix with the patch, you
> > > can either needinfo me or :ktucker
> > 
> > Thanks, that's good to know. But I'm more interested in automated testing to
> > prevent things like this from breaking in the future.
> 
> Geo should be able to provide more accurate answer for this one, but to my
> knowledge there is currently no automated test that can check whether the
> music is playing correctly.  (we can check it is playing per se though)

Checking that the system thinks the music is playing per its own back end APIs and Gaia display effects is straightforward enough. Checking that the signal being played would require a system level spy on the stream of some kind that we don't currently have. Checking that something is actually coming out of the headphones would require secondary equipment and the harness to coordinate it.

I'd be inclined to say that checking that the system is self-consistent is something we can/should do. Feel free to file a bug on that and mark it fxosqa-auto-backlog? in the QA Whiteboard field.

Anything else I'd check manually for the forseeable future, at least in terms of where any priority by the central automation team would probably go.

That said, if the functional team wants to develop the more complex dependencies for us, I'd always be happy to take them. I'd start with the stream intercept, since they could use that from their own integration tests first and get the bugs out before we tried to depend on it for acceptance.
Flags: needinfo?(gmealer)
Issue is still exist. Hema, could you help on this?

-------

Serial: e44ada75 (State: device)
Build ID               20150401162503
Gaia Revision          1ceca464053dee4a8bf10ea5abeef724d68c2ff2
Gaia Date              2015-04-01 09:49:30
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/427b4da96714
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150126.123500
Firmware Date          Mon Jan 26 12:35:10 EST 2015
Bootloader             L1TC000118D0
Flags: needinfo?(hkoka)
See Also: → 1107534
(In reply to Bobby Chien [:bchien] from comment #68)
> Issue is still exist. Hema, could you help on this?
> 
> -------
> 
> Serial: e44ada75 (State: device)
> Build ID               20150401162503
> Gaia Revision          1ceca464053dee4a8bf10ea5abeef724d68c2ff2
> Gaia Date              2015-04-01 09:49:30
> Gecko Revision        
> https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/427b4da96714
> Gecko Version          37.0
> Device Name            flame
> Firmware(Release)      4.4.2
> Firmware(Incremental)  eng.cltbld.20150126.123500
> Firmware Date          Mon Jan 26 12:35:10 EST 2015
> Bootloader             L1TC000118D0


Please see: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1116732#c62

Assigning to Bent based on conversation with overholt
Assignee: nobody → bent.mozilla
Flags: needinfo?(hkoka)
There have been a lot of changes on trunk. Can we test current trunk (3.0) again?
I cant reproduce on trunk any more.
Keywords: qawanted
(In reply to Gregor Wagner [:gwagner] from comment #70)
> There have been a lot of changes on trunk. Can we test current trunk (3.0)
> again?
> I cant reproduce on trunk any more.

It would be especially helpful if we could see a logcat with a DEBUG+opt build where this reproduces. So far the opt logcats don't show anything useful.
Ben, if the tree has been green all this time and this bug was reproducible, doesn't it mean that there's a gap in the tests?  :)
QA Contact: ktucker
I can no longer reproduce this on the latest Flame 3.0

Songs play as expected without issue.

Environmental Variables:
Device: Flame 3.0 (Full Flash)(KK)(319mb)
BuildID: 20150406010204
Gaia: ef61ebbe5de8c2c9fc2a8f74a12455044c3b82e9
Gecko: 4fe763cbe196
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

--------------------------------------

This issue still occurs on the latest Flame 2.2

The song will be stuck in a paused state. 

Environmental Variables:
Device: Flame 2.2 (Full Flash)(KK)(319mb)
Build ID: 20150406002503
Gaia: a6351e1197d54f8624523c2db9ba1418f2aa046f
Gecko: c3335a5d3063
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

I'll attach the logcat for the v2_2-flame-kk-eng-debug build shortly:
I guess a reverse regression window for master would help here: can we find the commit that fixed this?
I'm thinking it's some sort of timing issue. The fact that we can't reproduce it now doesn't necessarily mean it's fixed...
Reverse Regression Window:

Last Broken:
Device: Flame 3.0
BuildID: 20150327092142
Gaia: 0e7c8ade48129b3e03c5de8ae0452fd1f756535c
Gecko: bcc307ea64f4
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

First Working:
Device: Flame 3.0
BuildID: 20150327094838
Gaia: be2e04b19224e1c617ca513676c208bb1c2f8858
Gecko: 067e7f1f65cb
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Last Broken Gaia First Working Gecko: Issue DOES reproduce
Gaia: 0e7c8ade48129b3e03c5de8ae0452fd1f756535c
Gecko: 067e7f1f65cb

First Working Gaia Last Broken Gecko: Issue DOES NOT reproduce
Gaia: be2e04b19224e1c617ca513676c208bb1c2f8858
Gecko: bcc307ea64f4

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/0e7c8ade48129b3e03c5de8ae0452fd1f756535c...be2e04b19224e1c617ca513676c208bb1c2f8858

This looks to have been fixed by the landing for Bug 1147862
Frederik, can you take a look at this please? Anyway, we can get the fix for bug 1147862 uplifted to 2.2?
Depends on: 1147862
Flags: needinfo?(fbraun)
That bug really doesn't seem related. I think you're just seeing slightly different timing.
I really don't think this is the case. Believe me, I know how to reproduce this issue 100% of the time. I've done enough work on this issue to know. The push log is correct. It could be another issue in that push log that is the culprit here though since I am only making an educated guess but we can attempt to revert the gaia commit tomorrow and see if the issue reproduces again.
I can't really say whether this is related to bug 1147862 at all. I'm not very proficient in the inner workings of audio contexts.

It *might* just be, that FindMyDevice gets somehow activated when you lock the device, which would block the 'content' audio context. With my commit from bug 1147862, FindMyDevice uses a higher prioritized context, which would not block Music.

But this is really just an assumption, I'd rather have you talk this through with some folks from the Audio team.
Flags: needinfo?(fbraun)
Find My Device does indeed react to lockscreen activity.
I reverted the gaia commit: 6a31df26d40bbeb69e7a0a02e7e55d8c6619b0cf and I reproduced the issue again. This is the commit that fixed the issue on master.
Let's wrap this up if we can.

KTucker: can you still reproduce this on 2.2? The bug you pointed to has not been uplifted yet. Do we still need that uplift? Can you see any bugs where the ringtones app stops being able to play ringtones after the phone goes to sleep and wakes up again?

Frederik: is there any reason not to uplift bug 1147862 to 2.2? If that is the only fix we've got for this bug, we kind of need to have that uplifted. Would you nominate it for 2.2 uplift, please? Or explain why it can't be uplifted? Also, now that you're using 'ringer' priority instead of 'content' priority, can you say with confidence that FindMyDevice will not block the other apps (ringtones, privacy-panel and system) that use 'ringer'?  If the phone goes to sleep while the ringtones app is open, will we find that the user can't play ringtones when they wake it back up?

Dominic: You understand the audio competing policy as well as anyone, I think. Do comments 81 and 82 suggest to you that there is still a bug that needs to be fixed, or is it expected that a background app like FindMyDevice could block the Music app like that?  That is, can we just uplift the FMD patch and close this, or is there still work to do?  And do you understand why this bug only happens after we use the ringtones app (which uses audio-context-ringer)?

Ben: the bug is still assigned to you. Are you planning any further investigation or are you ready to reassign and/or close it? I note that comments 81 and 82 do not explain why it is necessary to save a song as a ringtone in order to make the bug reproduce. And I notice that FindMyDevice uses the settings database, as does the ringtones app. Could there still be something going on with the setting database?
Flags: needinfo?(ktucker)
Flags: needinfo?(fbraun)
Flags: needinfo?(dkuo)
Flags: needinfo?(bent.mozilla)
(In reply to David Flanagan [:djf] from comment #84)
> Frederik: is there any reason not to uplift bug 1147862 to 2.2? If that is
> the only fix we've got for this bug, we kind of need to have that uplifted.
> Would you nominate it for 2.2 uplift, please? Or explain why it can't be
> uplifted? Also, now that you're using 'ringer' priority instead of 'content'
> priority, can you say with confidence that FindMyDevice will not block the
> other apps (ringtones, privacy-panel and system) that use 'ringer'?  If the
> phone goes to sleep while the ringtones app is open, will we find that the
> user can't play ringtones when they wake it back up?

The only reason I can think of for not uplifting it, is that it would cause breakage with other apps, as you said. I have no indication that it should, but I think some testing would not hurt.
I am just on my way out for the weekend (local time), so please request the uplift in my stead.
Flags: needinfo?(fbraun)
KTucker: Do you know if anyone has actually tried applying the patch from bug 1147862 to the 2.2 branch to see if it resolves the bug there? Is that something you could try? I don't know anything about audio contexts, but I think that code has been in flux lately, so it would not be completely surprising if bug 1147862 was not enough to resolve this in 2.2

Jim: can you think of any workarounds you can apply if uplifting 1147862 does not fix this? If the bug is triggered by saving a ringtone and setting it as the default, could we just remove the "use as default ringtone" to prevent the bug? This would force the user to go to settings to change to the newly saved ringtone in a separate step.  Or could we resolve the bug by changing the ringtone share activity to be disposition:window rather than disposition:inline? (That's probably too big a change for a last minute blocker, though).
Flags: needinfo?(squibblyflabbetydoo)
I stand by comment 76: I don't think we really know what is wrong here, and we're just seeing some kind of timing problem that surfaced and then was hidden again. But I'll unassign myself for now.
Assignee: bent.mozilla → nobody
Flags: needinfo?(bent.mozilla)
Okay, I've requested uplift of bug 1147862, but we're going to need a lot of QA help to ensure that we can do that without breaking other apps.  I would be more comfortable if someone who understood audio contexts had a plausible hypothesis for what caused this bug, and could also explain why earlier on we thought it was an indexed db issue.

If I'm understanding the STR and the subsequent discussion correctly, we've got four apps involved in this bug:

1) The music app, which uses audio-context-content

2) The ringtones app, which uses audio-context-ringer, and which writes to indexeddb and sets dialer.ringtone in the settings db

3) The system app, which uses audio-context-{content,notification,ringer} and whose dialer_agent.js code which responds to changes to the dialer.ringtone setting and also responds to changes to the audio.volume.notification setting

4) The Find My Device app which used to use audio-context-content (but is changed to use audio-context-ringer by bug 1147862) and which (after the patch) sets audio.volume.notification. Somehow this app gets activated in some way when we lock the phone, but that part is unclear.

So we've got four apps that want to be able to make sounds, three of which read or write the settings db.

Does that help anyone understand the bug?
Jim: since Ben has unassigned himself, are you able to take this bug and see if you can move it forward? We can't afford to have an unowned blocker this close to the FC date.
(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #87)
> I stand by comment 76: I don't think we really know what is wrong here, and
> we're just seeing some kind of timing problem that surfaced and then was
> hidden again. But I'll unassign myself for now.

I agree that we don't really understand what is going on here and think this needs more investigation. But we're only a few days away from the FC deadline, so we need to reach some kind of resolution for 2.2 ASAP. Before you leave this bug completely, do you have any thoughts about what kind of timing problem we might be seeing?  Does comment 88 give you any ideas about what might be going on?
Flags: needinfo?(bent.mozilla)
I don't see how I could possibly come up with a patch that's simpler and less prone to breakage than a +6/-5 line patch that (apparently) fixes the issue properly. (I speak of course of bug 1147862.)
Flags: needinfo?(squibblyflabbetydoo)
(In reply to David Flanagan [:djf] from comment #90)
> Does comment 88 give you any ideas about what might be going on?

No, it really doesn't. Changing audio priority might change cpu priority? Or change thread scheduling somehow? Or change memory pressure? We could be looking at a race in the guts of IndexedDB, or a race in IPC messages across different protocols, or a race in the JS of one of the apps. There are way too many possibilities to guess here.
Flags: needinfo?(bent.mozilla)
If bug 1147862 makes things work then you should just take that I would say.
Jim: since it looks like your other blockers are resolved, can you take this bug and see whether uplifting 1147862 fixes it on 2.2? (My question about a workaround was because we don't yet know whether 1147862 will fix it on 2.2 and whether that bug is safe to uplift to 2.2)
Flags: needinfo?(squibblyflabbetydoo)
FYI, after applying the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1147862 to the latest 2.2 gaia, I was unable to repro this issue, but qanalysts will also be checking on the patched 2.2 build for any regressions.
Thank you for testing that, No-Jun.  As I mentioned in comment #84, I'm worried that the patch for that bug will just move the problem to other apps, so if we are going to uplift it we'll need to be sure to do some extra testing of apps (like ringtones) that play audio.  Someone like Dominic who understands audio channels better than I do could probably assess what should be tested and what the risks are.
Following extensive exploratory testing on Flame 2.2 with the patch from bug 1147862 applied I have observed no regressions or otherwise serious issues. Exploratory touched on Music, Video, Ringtones, and FM Radio over the course of testing.

Device: Flame 2.2
Build ID: 20150424162839
Gaia: 265ca0bc9408c21fc4b25a259fcee7fb642cd06b
Gecko: Unknown
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(ktucker)
Looks like everything is good on 2.2, so we should probably uplift bug 1147862.
Flags: needinfo?(squibblyflabbetydoo)
Thank you, Brogan.  After thinking about this some more, I've asked for more exploratory testing as well. See https://bugzilla.mozilla.org/show_bug.cgi?id=1147862#c15
(In reply to David Flanagan [:djf] from comment #84)
> Dominic: You understand the audio competing policy as well as anyone, I
> think. Do comments 81 and 82 suggest to you that there is still a bug that
> needs to be fixed, or is it expected that a background app like FindMyDevice
> could block the Music app like that?  That is, can we just uplift the FMD
> patch and close this, or is there still work to do?  And do you understand
> why this bug only happens after we use the ringtones app (which uses
> audio-context-ringer)?

I don't know why FMD app used "content" channel type to produce a "ringer" behavior(maybe  Frederik can explain it), it's apparently a bug and bug 1147862 fixed it on master. Even though the FMD's channel type was set wrong, FMD with content channel shouldn't block Music's content channel, because if there are two apps with content channels are competing, the foreground app wins, the background app will be interrupted, or if both apps are in foreground(document.hidden is false), they can produce sounds at the same time. In this bug Music should be the foreground app? but I didn't see FMD...

Uplifting bug 1147862 seems reasonable if it does fix this bug on v2.2, it also corrects FMD's channel type. If FMD is just an app that rings the ringtone, then uplifting should be enough I think, but I don't exactly know what FMD does. I have to investigate this issue to understand what happen here if this bug still needs me.
Clear the needinfo.
Flags: needinfo?(dkuo)
I just spent some time looking at FMD. It listens to changes in dialer.ringtone. So when the ringtones app sets a new ringtone, both the system app and FMD wake up and set the new ringtone on their respective audio elements.  The system app uses 'ringer' as the prioirty. FMD uses 'content' on 2.2 and 'ringer' on master.

It looks like FMD also gets a message when the user unlocks the phone. If the user has a passcode enabled for their lockscreen, then FMD creates a high-priority wakelock but doesn't actually do anything with it.  I've got no idea whether the wakelock code could interfere with anything else. And I don't think the STR for this bug required there to be a passcode on the phone.
The patch from bug 1147862 has been uplifted, so I'm clearing the blocking flag on this bug, since this means it is no longer reproducible in that release so there is nothing to block on.
blocking-b2g: 2.2+ → ---
Ben: We never figured out what was happening here, so there is presumably still some kind of bug lurking. But now that bug 1147862 has been uplifted we no longer have a way to reproduce it.  I'm inclined to close the bug, but wanted to ask you first, in case you want to take it back and keep it open, or file a followup. Please go ahead and close if if you think that is the right course of action.
Flags: needinfo?(bent.mozilla)
Yeah, I don't think it's worth holding this bug open.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bent.mozilla)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: