989570 - [Camera][Madai][Buri] Homescreen wallpaper turned black during gallery testing

Status: VERIFIED FIXED

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

Description

[Marcia Knous [:marcia]]

Attachment: Wallpaper on homescreen

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

Comment 1

[Marcia Knous [:marcia]]

Attachment: Screenshot of lockscreen

Comment 2

[David Flanagan [:djf]]

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.

Comment 3

[Hema Koka [:hema]]

Tim,

This is happening on master, please help have someone in your team take a look.

THanks
Hema

Comment 4

[Jason Smith [:jsmith]]

bug 990802 has consistent STR, so I'm going to dupe to that bug.

Comment 5

[Jason Smith [:jsmith]]

(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.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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.

Comment 7

[Gabriele Svelto [:gsvelto]]

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

[Hema Koka [:hema]]

Milan, 

Need your team's help with this one...

thanks!
hema

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Sure we can help - do we have an STR and a regression range?

Comment 10

[Jason Smith [:jsmith]]

We can't really do a regression range until we have clear STR to reproduce the bug.

Comment 11

[Hema Koka [:hema]]

NI marcia for STR

Comment 12

[Marcia Knous [:marcia]]

(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.

Comment 13

[Hema Koka [:hema]]

Reopen if someone is still able to reproduce it.

Thanks
Hema

Comment 14

[Tony Nguyen]

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

[Tony Nguyen]

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

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

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

Comment 17

[Jason Smith [:jsmith]]

Can we get a window here on b2g-inbound?

Comment 18

[Pi Wei Cheng [:piwei] (inactive)]

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

Comment 19

[Jason Smith [:jsmith]]

bug 949941 likely caused this regression.

Comment 20

[Jason Smith [:jsmith]]

This should be present on Tarako as well - can someone confirm this?

Comment 21

[Andrew Sutherland [:asuth] (he/him)]

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

[Pi Wei Cheng [:piwei] (inactive)]

(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

Comment 23

[Hema Koka [:hema]]

regression issue, blocking it -- use comment 14 for STR

Comment 24

[Andrew Overholt [:overholt]]

I'm going to follow up on bug 931224.

Comment 25

[Hema Koka [:hema]]

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)

Comment 26

[Hema Koka [:hema]]

(In reply to Andrew Overholt [:overholt] from comment #24)
> I'm going to follow up on bug 931224.

thanks!

Comment 27

[Andrew Overholt [:overholt]]

I emailed the relevant parties yesterday and am hoping to hear back on bug 931224 ASAP.  I'll be off tomorrow, FWIW.

Comment 28

[Gregor Wagner [:gwagner]]

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?

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 30

[Andrew Sutherland [:asuth] (he/him)]

(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.

Comment 31

[Gregor Wagner [:gwagner]]

qawanted for verification as asked in comment 29

Comment 32

[Jason Smith [:jsmith]]

(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.

Comment 33

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I'm going to do the platform fix in bug 982779.

Comment 34

[Gregor Wagner [:gwagner]]

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.

Comment 35

[Andrew Sutherland [:asuth] (he/him)]

: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.)

Comment 36

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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).

Comment 37

[Kai-Chih Hu [:khu]]

(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.

Comment 38

[Andrew Overholt [:overholt]]

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.

Comment 39

[Kai-Chih Hu [:khu]]

(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.

Comment 40

[Ben Turner (not reading bugmail, use the needinfo flag!)]

It's in!

Comment 41

[Andrew Overholt [:overholt]]

qawanted to confirm if the steps in comment 14 are reproducible with a build including the fix in bug 982779.

Comment 42

[Pi Wei Cheng [:piwei] (inactive)]

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

Comment 43

[Jason Smith [:jsmith]]

Right - so let's mark this then as fixed by bug 982779.

Comment 44

[Andrew Overholt [:overholt]]

\o/  Thanks, Pi Wei Cheng!

Comment 45

[Dean R. Gomez (DeanG)]

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

[Dean R. Gomez (DeanG)]

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

Comment 47

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Updating steps a duplicate testcase to cover this bug.

https://moztrap.mozilla.org/manage/case/1900/

Comment 48

[KTucker [:KTucker][Inactive 3/4/2016]]

Updated this test case to the steps in comment 14

https://moztrap.mozilla.org/manage/case/1900/