Closed
Bug 989570
Opened 10 years ago
Closed 10 years ago
[Camera][Madai][Buri] Homescreen wallpaper turned black during gallery testing
Categories
(Firefox OS Graveyard :: Gaia::Homescreen, defect)
Tracking
(blocking-b2g:1.4+, firefox30 wontfix, firefox31 wontfix, firefox32 fixed, b2g-v1.3 unaffected, b2g-v1.3T unaffected, b2g-v1.4 verified, b2g-v2.0 verified)
Tracking | Status | |
---|---|---|
firefox30 | --- | wontfix |
firefox31 | --- | wontfix |
firefox32 | --- | fixed |
b2g-v1.3 | --- | unaffected |
b2g-v1.3T | --- | unaffected |
b2g-v1.4 | --- | verified |
b2g-v2.0 | --- | verified |
People
(Reporter: marcia, Assigned: asuth)
References
()
Details
(Keywords: regression, Whiteboard: [m+], [1.4-camera-exploratory])
Attachments
(2 files)
Buri, while running with the latest master. Gaia 287195d1fed2e6c883745d7091a4c05e56c4dbb7 SourceStamp bb4dd9872236 BuildID 20140327092814 Version 31.0a1 STR: 1. During a session editing Gallery, I lost my wallpaper. Later the wallpaper came back, but now it does not match what is on the lockscreen. See attached photos. Expected: Lockscreen and homescreen wallpapers should match
Reporter | ||
Comment 1•10 years ago
|
||
Updated•10 years ago
|
Keywords: steps-wanted
Updated•10 years ago
|
Severity: normal → major
Updated•10 years ago
|
Whiteboard: [m+]
Updated•10 years ago
|
Flags: needinfo?(dflanagan)
Comment 2•10 years ago
|
||
This sounds very weird. Is it reproducible? You weren't doing anything to actually set the wallpaper were you? If not, then this sounds like a graphics bug. Do you know what made the homescreen wallpaper come back? Did the homescreen get killed and restarted? When this happens does the lockscreen wallpaper come back if you reboot the phone? I think I've heard that there were big lockscreen changes recently, but I don't know anything about those. If we can get STR for this bug, I think we should alert the lockscreen devs as well as the homescreen devs, and maybe also someone who can look at the underlying graphics.
Flags: needinfo?(dflanagan)
Comment 3•10 years ago
|
||
Tim, This is happening on master, please help have someone in your team take a look. THanks Hema
Flags: needinfo?(timdream)
Comment 4•10 years ago
|
||
bug 990802 has consistent STR, so I'm going to dupe to that bug.
No longer blocks: 983405
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(timdream)
Keywords: steps-wanted
Resolution: --- → DUPLICATE
Comment 5•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #4) > bug 990802 has consistent STR, so I'm going to dupe to that bug. > > *** This bug has been marked as a duplicate of bug 990802 *** Actually I'm not 100% they are the same problem, but they might be related.
Keywords: steps-wanted
Updated•10 years ago
|
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 6•10 years ago
|
||
There aren't anything in Gaia that change/set/unset the wallpaper except the place when the user changes the wallpaper, in bootstrap.js. So this very likely is a graphics bug. We still need a consistent repro step though.
Component: Gaia::Homescreen → General
Comment 7•10 years ago
|
||
Too bad we don't have a logcat for this. If editing in the gallery triggered a low-memory condition it might be possible this was a side-effect of purging the image cache or some related platform-specific issue.
Comment 8•10 years ago
|
||
Milan, Need your team's help with this one... thanks! hema
Flags: needinfo?(milan)
Comment 9•10 years ago
|
||
Sure we can help - do we have an STR and a regression range?
Flags: needinfo?(milan)
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Comment 10•10 years ago
|
||
We can't really do a regression range until we have clear STR to reproduce the bug.
Keywords: regressionwindow-wanted
Reporter | ||
Comment 12•10 years ago
|
||
(In reply to David Flanagan [:djf] from comment #2) > This sounds very weird. Is it reproducible? You weren't doing anything to > actually set the wallpaper were you? If not, then this sounds like a > graphics bug. > > Do you know what made the homescreen wallpaper come back? Did the > homescreen get killed and restarted? When this happens does the lockscreen > wallpaper come back if you reboot the phone? > > I think I've heard that there were big lockscreen changes recently, but I > don't know anything about those. > > If we can get STR for this bug, I think we should alert the lockscreen devs > as well as the homescreen devs, and maybe also someone who can look at the > underlying graphics. djf: Yes, I wasn't actually changing any wallpaper when this happened. Since it happened I haven't been able to reproduce it at all.
Flags: needinfo?(mozillamarcia.knous)
Comment 13•10 years ago
|
||
Reopen if someone is still able to reproduce it. Thanks Hema
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → WORKSFORME
Updated•10 years ago
|
Keywords: steps-wanted
Comment 14•10 years ago
|
||
I ran into this issue on the latest Buri v1.4 mozRIL build. Repro Steps: 1) Update Buri to BuildID: 20140410000201 2) Tap and hold on homescreen 3) Tap 'Change Wallpaper' 4) Tap 'Camera' 5) Tap the capture button to take a photo 6) Tap 'Select' button 7) Press power button twice Actual: Lockscreen is displayed with black background Expected: Lockscreen shares same background has homescreen Environmental Variables: Device: Buri v1.4 mozRIL BuildID: 20140411000202 Gaia: 6c50349f41d40ba175ea0fc0c2c2cbd739ba7170 Gecko: 28b419f0e857 Version: 30.0a2 Firmware Version: v1.2-device.cfg Notes: The lockscreen background matches the homescreen after the device has been restarted. Repro frequency: 5/5 - 100% See attached: logcat URL: http://youtu.be/g49bBGwvlzo
Comment 15•10 years ago
|
||
This issue does reproduces on the 03/26 v1.4 build. Environmental Variables: Device: Buri v1.4 mozRIL BuildID: 20140326000201 Gaia: 7e705dd4718d528974d99ac31866318d7e201152 Gecko: 4889124accfa Version: 30.0a2 Firmware Version: v1.2-device.cfg This issue does not reproduce on the latest v1.3 build. Environmental Variables: Device: Buri v1.3 mozRIL BuildID: 20140411004001 Gaia: 05f136fa6edbd30156030a86a13ef182dc4d40b5 Gecko: 70477239b3ff Version: 28.0 Firmware Version: v1.2-device.cfg
status-b2g-v1.3:
--- → unaffected
Whiteboard: [m+] → [m+], [1.4-camera-exploratory]
Updated•10 years ago
|
blocking-b2g: --- → 1.4?
Keywords: regression,
regressionwindow-wanted
Updated•10 years ago
|
QA Contact: pcheng
Comment 16•10 years ago
|
||
The following regression window was found using 1.4 Aurora Tinderbox builds. Last Working Environmental Variables: Device: Buri v1.4 Aurora MOZ BuildID: 20140318144702 Gaia: c03a6af9028c4b74a84b5a98085bbb0c07261175 Gecko: b07ecc057abf Version: 30.0a2 Firmware Version: v1.2-device.cfg First Broken Environmental Variables: Device: Buri v1.4 Aurora MOZ BuildID: 20140319013702 Gaia: a6f0e98007d220d39e045f5bbf901b7d86f59698 Gecko: 6439da7b39ef Version: 30.0a2 Firmware Version: v1.2-device.cfg Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce Gaia: c03a6af9028c4b74a84b5a98085bbb0c07261175 Gecko: 6439da7b39ef Last Working Gecko / First Broken Gaia: Issue DOES reproduce Gaia: a6f0e98007d220d39e045f5bbf901b7d86f59698 Gecko: b07ecc057abf Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/c03a6af9028c4b74a84b5a98085bbb0c07261175...a6f0e98007d220d39e045f5bbf901b7d86f59698
Keywords: regressionwindow-wanted
Updated•10 years ago
|
Component: General → Gaia::Camera
Updated•10 years ago
|
Component: Gaia::Camera → Gaia::Homescreen
Comment 18•10 years ago
|
||
1.4 regression window from b2g-inbound: Last Working Environmental Variables: Device: Buri v1.4 Master MOZ BuildID: 20140317095627 Gaia: 3ad16c6017b78f6f7d0008f75ac16af011fcb14c Gecko: ca88f9016809 Version: 30.0a1 Firmware Version: v1.2-device.cfg First Broken Environmental Variables: Device: Buri 1.4 Master MOZ BuildID: 20140317101128 Gaia: 99890f3d9309ed5c696e110533aea5b6281f65d6 Gecko: a0618b266f28 Version: 30.0a1 Firmware Version: v1.2-device.cfg Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce Gaia: 3ad16c6017b78f6f7d0008f75ac16af011fcb14c Gecko: a0618b266f28 Last Working Gecko / First Broken Gaia: Issue DOES reproduce Gaia: 99890f3d9309ed5c696e110533aea5b6281f65d6 Gecko: ca88f9016809 Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/3ad16c6017b78f6f7d0008f75ac16af011fcb14c...99890f3d9309ed5c696e110533aea5b6281f65d6
Keywords: regressionwindow-wanted
Comment 19•10 years ago
|
||
bug 949941 likely caused this regression.
Blocks: 949941
Component: Gaia::Homescreen → Gaia::Camera
Comment 20•10 years ago
|
||
This should be present on Tarako as well - can someone confirm this?
Keywords: qawanted
Assignee | ||
Comment 21•10 years ago
|
||
I just looked into this. This is a mozSettings bug made apparent by a platform bug. mozSettings has fallen into the common trap of not re-get()-ing a Blob/File it has put() to IndexedDB when broadcasting changes to observers. (The lock-screen gets ahold of the new background via an observer.) It should re-get what it has persisted if it was a Blob/File, or just always, if it doesn't want to check if there's a File/Blob in there. The platform issue is that we have, in general, noticed that memory-backed Blobs seem to not properly be remoted across process boundaries in their entirety or have some related life-cycle issue so that they end up dying when their originating process dies. It's possible that the File wrapping in bug 949941 is exacerbating whatever the underlying platform bug thing is. I will file a DOM bug on the mozSettings problem and mark it as blocking this bug and call this bug out in the platform "Blobs are dying!!!!" bug. For memory-usage reasons, we really do want mozSettings to "properly" be converting this to an IndexedDB-backed File blob. I'm leaving this bug in camera for now since I'm guessing this is where any duplicate bugs would be filed, but it might be more appropriate to put the bug in lock-screen or home-screen. Unsure.
Comment 22•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #20) > This should be present on Tarako as well - can someone confirm this? This issue is NOT reproducible on Tarako. Following repro steps at Comment 14, the wallpaper does not turn black on lockscreen. v1.3T Environmental Variables: Device: Tarako v1.3T BuildID: 20140415004002 Gaia: 44ff6248c28ff83b9ad1161847a176399f93d3bb Gecko: 28aea220e338 Version: 28.1 Firmware Version: sp6821
Keywords: qawanted
Comment 23•10 years ago
|
||
regression issue, blocking it -- use comment 14 for STR
blocking-b2g: 1.4? → 1.4+
Comment 25•10 years ago
|
||
The component here probably belongs in Lockscreen/Homescreen -- no action being taken by camera/gallery guys on this bug at the moment (dependency: https://bugzilla.mozilla.org/show_bug.cgi?id=931224)
Component: Gaia::Camera → Gaia::Homescreen
Comment 26•10 years ago
|
||
(In reply to Andrew Overholt [:overholt] from comment #24) > I'm going to follow up on bug 931224. thanks!
Comment 27•10 years ago
|
||
I emailed the relevant parties yesterday and am hoping to hear back on bug 931224 ASAP. I'll be off tomorrow, FWIW.
Flags: needinfo?(overholt)
Comment 28•10 years ago
|
||
This is a regression caused by 949941 if I read the comments correctly. The solution seems to be a new feature to the settings API and we are way past FC deadline. Can we go back to the state where we don't rely on file backed blobs?
Assignee | ||
Comment 29•10 years ago
|
||
The underlying underlying problem is a platform problem related to the handling of memory-backed Blobs. *Anything* passing memory-backed Blobs across process boundaries is playing a game of Russian roulette (that may be a certainty in certain cases). The secondary underlying problem is a bug in mozSettings. It is conceivable the gold-plating I put in bug 949941 to wrap the resized memory-backed Blob generated by Canvas' toBlob() in a File to propagate the source 'name' (*only* if one existed; I don't know if this code path is being exercised). If you back anything out, just back out that teeny piece there. If you back out the whole thing you're going to regress the e-mail and SMS use-cases which are arguably both more important than this somewhat edge-casey where you set the system wallpaper based on a freshly taken picture. Also note that as far as I can tell :jsmith's comment 19 is based on skimming the gaia changelog (and it's definitely a good guess!). Since there are underlying platform issues where timing may play a major factor, it would be advisable to test with the prior gaia commit and the bug 949941-fixed commits using the same gecko build to ensure that this is exactly what is happening. I'd also throw in a console.log() call to note if the gold-plated logic path is in effect since if it's not being triggered then it's bad news.
Assignee | ||
Comment 30•10 years ago
|
||
(In reply to Andrew Sutherland (:asuth) from comment #29) > It is conceivable the gold-plating I put in bug 949941 to wrap the resized > memory-backed Blob generated by Canvas' toBlob() in a File to propagate the > source 'name' (*only* if one existed; I don't know if this code path is > being exercised) ... is causing us to lose the game of russian roulette and the platform bug to be causally/immediately triggered.
Updated•10 years ago
|
QA Contact: pcheng
Comment 32•10 years ago
|
||
(In reply to Gregor Wagner [:gwagner] from comment #31) > qawanted for verification as asked in comment 29 That's something we can't do. That requires a funky custom build setup.
Keywords: qawanted
I'm going to do the platform fix in bug 982779.
Comment 34•10 years ago
|
||
How do we want so solve this? bent, how risky is the patch in bug 982779 and should we fix this bug by relying on the new code? Andrew, you mentioned earlier: If you back anything out, just back out that teeny piece there... Can we try this teeny piece backout and see if it fixes the problem? It's probably less risky than relying on bug 982779.
Flags: needinfo?(bugmail)
Flags: needinfo?(bent.mozilla)
Assignee | ||
Comment 35•10 years ago
|
||
:bent got down to the root cause on bug 982779, so I think he's most qualified to dictate what fix or workaround we can use here. (My guess workaround-wise is that since it sounds like what the Blob Canvas is minting is already inherently ending up as a mystery blob then no backout variation would be sufficient. We would need to extract the contents of the Blob and mint a new memory-backed Blob (which we would not wrap in a File or other composite Blob) that would not end up as a mystery Blob. But then I'm still not clear on whether other Activity stuff would betray us given the weird hacks that exist in the code that :bent removes in his patch.)
Flags: needinfo?(bugmail)
I'm nervous about changing platform-level blob code this late for 1.4. However, I think asuth is right, the only workaround would probably be to duplicate a photo in memory, and that has plenty of inherent risk also. Let's just land bug 982779 and make sure to focus testing on blob-related stuff (wallpaper, ringtone, camera, activities).
Flags: needinfo?(bent.mozilla)
Comment 37•10 years ago
|
||
(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #36) > I'm nervous about changing platform-level blob code this late for 1.4. > However, I think asuth is right, the only workaround would probably be to > duplicate a photo in memory, and that has plenty of inherent risk also. > > Let's just land bug 982779 and make sure to focus testing on blob-related > stuff (wallpaper, ringtone, camera, activities). Thanks, Ben! So, do you know who would be the best person to work on this bug? Thanks.
Flags: needinfo?(bent.mozilla)
Comment 38•10 years ago
|
||
Once we get the patch in bug 982779 to stick, we will need to uplift it to 1.4 and then we shouldn't need a workaround (or any work?) here. I'll make this depend upon bug 982779 (which I also marked 1.4+) and <spins wheel of misfortune> make asuth the assignee here to follow up when that has landed on 1.4.
Assignee: nobody → bugmail
Flags: needinfo?(bent.mozilla)
Comment 39•10 years ago
|
||
(In reply to Andrew Overholt [:overholt] from comment #38) > Once we get the patch in bug 982779 to stick, we will need to uplift it to > 1.4 and then we shouldn't need a workaround (or any work?) here. > > I'll make this depend upon bug 982779 (which I also marked 1.4+) and <spins > wheel of misfortune> make asuth the assignee here to follow up when that has > landed on 1.4. Thank you, Andrew. That's very clear and helpful.
It's in!
Comment 41•10 years ago
|
||
qawanted to confirm if the steps in comment 14 are reproducible with a build including the fix in bug 982779.
Keywords: qawanted
Updated•10 years ago
|
QA Contact: pcheng
Comment 42•10 years ago
|
||
Issue appears fixed on today's master build with Buri. Following repro on comment 14, wallpaper does not turn black on lockscreen. Issue persists on today's 1.4 but I guess it's because it hasn't been lifted to 1.4. Tested on: (no repro) Device: Buri MOZ BuildID: 20140507040203 Gaia: 870a5c518742665d36b17e7e88c2ab07d440b94c Gecko: 417acde736e7 Version: 32.0a1 Firmware Version: v1.2-device.cfg (issue repros) Device: Buri MOZ BuildID: 20140507000202 Gaia: bac831d2ebc567f0939e41fbd8a4c15ef183b954 Gecko: 8040ccd0d4b1 Version: 30.0 Firmware Version: v1.2-device.cfg
Keywords: qawanted
Comment 43•10 years ago
|
||
Right - so let's mark this then as fixed by bug 982779.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 44•10 years ago
|
||
\o/ Thanks, Pi Wei Cheng!
Updated•10 years ago
|
status-b2g-v1.3T:
--- → unaffected
status-b2g-v2.0:
--- → fixed
status-firefox30:
--- → wontfix
status-firefox31:
--- → wontfix
status-firefox32:
--- → fixed
Target Milestone: --- → 2.0 S1 (9may)
Updated•10 years ago
|
Updated•10 years ago
|
Updated•10 years ago
|
Comment 45•10 years ago
|
||
This issue is verified as fixed on Flame 2.0 2.0F Environmental Variables: Device: Flame 2.0F BuildID: 20140521160200 Gaia: 40abb245b1e61df67757ba3747e2f73202e5182b Gecko: a7d685480bf2 Version: 32.0a1 Firmware Version: v10F-3 This issue is verified as fixed on Open_C 2.0 2.0 Environmental Variables: Device: Open_C 2.0 BuildID: 20140522040230 Gaia: ef66efa34ed8a559c8998bde688fae88eb943a7a Gecko: b40296602083 Version: 32.0a1 Firmware Version: P821A10V1.0.0B06_LOG_DL
Comment 46•10 years ago
|
||
This issue is verified as fixed on Open_C 1.4 Open C 1.4: 1.4 Environmental Variables: Device: Open_C 1.4 BuildID: 20140522000200 Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34 Gecko: c3c0c57daef8 Version: 30.0 Firmware Version: P821A10V1.0.0B06_LOG_DL This issue is verified as fixed on Flame 1.4 1.4F Environmental Variables: Device: Flame 1.4F BuildID: 20140522000200 Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34 Gecko: c3c0c57daef8 Version: 30.0 Firmware Version: v10F-3 This issue is verified as fixed on Buri 1.4 1.4 Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140522000200 Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34 Gecko: c3c0c57daef8 Version: 30.0 Firmware Version: v1.2-device.cfg
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
Updating steps a duplicate testcase to cover this bug. https://moztrap.mozilla.org/manage/case/1900/
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Comment 48•10 years ago
|
||
Updated this test case to the steps in comment 14 https://moztrap.mozilla.org/manage/case/1900/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Flags: in-moztrap+
You need to log in
before you can comment on or make changes to this bug.
Description
•