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)
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)
[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
Reporter | ||
Updated•9 years ago
|
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → affected
Reporter | ||
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
This works fine for me on the latest 2.2 build on a Flame.
Comment 3•9 years ago
|
||
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)
Comment 4•9 years ago
|
||
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)
Updated•9 years ago
|
Flags: needinfo?(mlien)
Keywords: regression,
regressionwindow-wanted
Comment 5•9 years ago
|
||
The latest v2.1 seems cannot reproduce this, and I found bug 1101448 should be a same issue.
Updated•9 years ago
|
QA Contact: ktucker
Updated•9 years ago
|
status-b2g-master:
--- → affected
Comment 7•9 years ago
|
||
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.
status-b2g-master:
affected → ---
Comment 8•9 years ago
|
||
Investigating this further because somehow I just reproduced this on 2.2 using the duplicate bug's steps.
Comment 9•9 years ago
|
||
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.
status-b2g-v2.0:
--- → unaffected
status-b2g-master:
--- → affected
Comment 10•9 years ago
|
||
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
Comment 11•9 years ago
|
||
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)
Comment 13•9 years ago
|
||
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
Comment 14•9 years ago
|
||
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.
Updated•9 years ago
|
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.
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Updated•9 years ago
|
Assignee: nobody → squibblyflabbetydoo
Comment 17•9 years ago
|
||
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
status-b2g-v2.1S:
--- → unaffected
Comment 18•9 years ago
|
||
Happen time 5:10
Comment 19•9 years ago
|
||
Happen time 5:10
Comment 20•9 years ago
|
||
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)
Comment 22•9 years ago
|
||
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)
Comment 23•9 years ago
|
||
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.
Comment 24•9 years ago
|
||
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)
Comment 25•9 years ago
|
||
(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)
Comment 27•9 years ago
|
||
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?
Comment 28•9 years ago
|
||
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.
Keywords: regressionwindow-wanted
Comment 29•9 years ago
|
||
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)
Keywords: regressionwindow-wanted
QA Contact: ktucker
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Comment 30•9 years ago
|
||
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)
Comment 31•9 years ago
|
||
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.
Comment 32•9 years ago
|
||
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)
Comment 33•9 years ago
|
||
(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)
Updated•9 years ago
|
Flags: needinfo?(lissyx+mozillians)
Comment 34•9 years ago
|
||
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)
Comment 35•9 years ago
|
||
Can't reproduce the bug with all the debug flags on.
Comment 36•9 years ago
|
||
(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)
Comment 37•9 years ago
|
||
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)
Comment 38•9 years ago
|
||
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
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Comment 39•9 years ago
|
||
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)
Comment 40•9 years ago
|
||
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)
Comment 41•9 years ago
|
||
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)
Comment 42•9 years ago
|
||
Hub, Could you please help with this? Thanks much! Hema
Flags: needinfo?(hkoka) → needinfo?(hub)
Flags: needinfo?(nhirata.bugzilla)
Comment 43•9 years ago
|
||
I can reproduce. It doesn't seem to be trivial to revert. Looking further if I can do it.
Comment 44•9 years ago
|
||
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)
Comment 45•9 years ago
|
||
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)
Updated•9 years ago
|
Assignee: squibblyflabbetydoo → nobody
Comment 46•9 years ago
|
||
(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)
Comment 47•9 years ago
|
||
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.
Comment 48•9 years ago
|
||
(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.
Comment 49•9 years ago
|
||
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.
Comment 50•9 years ago
|
||
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)
Comment 52•9 years ago
|
||
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)
Comment 53•9 years ago
|
||
> 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)
Comment 54•9 years ago
|
||
Hi Ben, do you mind to take a look as Comment 53 mentioned?
Flags: needinfo?(bent.mozilla)
Comment 55•9 years ago
|
||
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.
Updated•9 years ago
|
Keywords: qaurgent,
regressionwindow-wanted
Comment 56•9 years ago
|
||
Here is the video of me reproducing this issue on the First Broken Build in the regression window. http://youtu.be/8E4MASsVVoU
Updated•9 years ago
|
Comment 57•9 years ago
|
||
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)
Comment 58•9 years ago
|
||
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)
Comment 59•9 years ago
|
||
I think this should direct to Ben not Dominic.
Flags: needinfo?(dkuo) → needinfo?(bent.mozilla)
Comment 60•9 years ago
|
||
Andrew, Who can help in Ben's absence? Thanks Hema
Flags: needinfo?(overholt)
Comment 61•9 years ago
|
||
Update: Andrew Overholt is working with Ben to see when we can get this landed. Andrew: Please move to the right component. Thanks Hema
Comment 62•9 years ago
|
||
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)
Updated•9 years ago
|
Flags: needinfo?(overholt)
Comment 64•9 years ago
|
||
(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.
Comment 66•9 years ago
|
||
(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)
Comment 68•9 years ago
|
||
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)
Comment 69•9 years ago
|
||
(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)
Comment 70•9 years ago
|
||
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? :)
Updated•9 years ago
|
QA Contact: ktucker
Comment 73•9 years ago
|
||
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:
Updated•9 years ago
|
Comment 74•9 years ago
|
||
Comment 75•9 years ago
|
||
I guess a reverse regression window for master would help here: can we find the commit that fixed this?
Keywords: regressionwindow-wanted
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...
Comment 77•9 years ago
|
||
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
Keywords: regressionwindow-wanted
Comment 78•9 years ago
|
||
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.
Comment 80•9 years ago
|
||
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.
Comment 81•9 years ago
|
||
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)
Comment 82•9 years ago
|
||
Find My Device does indeed react to lockscreen activity.
Comment 83•9 years ago
|
||
I reverted the gaia commit: 6a31df26d40bbeb69e7a0a02e7e55d8c6619b0cf and I reproduced the issue again. This is the commit that fixed the issue on master.
Comment 84•9 years ago
|
||
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)
Comment 85•9 years ago
|
||
(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)
Comment 86•9 years ago
|
||
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).
Updated•9 years ago
|
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)
Comment 88•9 years ago
|
||
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?
Comment 89•9 years ago
|
||
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.
Comment 90•9 years ago
|
||
(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)
Comment 91•9 years ago
|
||
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.
Comment 94•9 years ago
|
||
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)
Comment 95•9 years ago
|
||
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.
Comment 96•9 years ago
|
||
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.
Comment 97•9 years ago
|
||
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
Updated•9 years ago
|
Flags: needinfo?(ktucker)
Comment 98•9 years ago
|
||
Looks like everything is good on 2.2, so we should probably uplift bug 1147862.
Flags: needinfo?(squibblyflabbetydoo)
Comment 99•9 years ago
|
||
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
Comment 100•9 years ago
|
||
(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.
Comment 102•9 years ago
|
||
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.
Comment 103•9 years ago
|
||
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+ → ---
Comment 104•9 years ago
|
||
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.
Description
•