1008026 - [Midori][Home Screen][Wallpaper] (v1.3 only) The wallpaper flicker in select wallpaper screen when slide screen

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Wallpaper, defect, P1)

Description

[sync-1]

Mozilla build ID:20140422024003
 
 Created an attachment (id=737260)
 VEDIO
 
 DEFECT DESCRIPTION:
  The wallpaper flicker in select wallpaper screen when slide screen
 
  REPRODUCING PROCEDURES:
  1.Turn on MS
  2.Long press idle screen->tap "Change Wallpaper"->tap "Wallpaper" into select wallpaper screen.
  3.Slide up and down->the wallpaper will flicker-->KO
 
 
  EXPECTED BEHAVIOUR:
  KO：The wallpaper should not flicker.
 
  COMMENTS:
  Those picture's resolution in wallpaper resource directory is 540*960.
  
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
  Free Test
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
  Medium
  
  REPRODUCING RATE:
  10/10

Comment 1

[liangxin]

Attachment: VID_0008.3gp

wallpaper flicker video

Comment 2

[liangxin]

Attachment: VID_20140507_112105_Compress.MP4

Comment 3

[sync-1]

Attachment: VEDIO

Comment 4

[liangxin]

Attachment: jrdlog.rar

jrdlog

Comment 5

[sync-1]

Attachment: jrdlog_669144

Comment 6

[sync-1]

Dear Mozilla,

Have anyone check this PR? This phenomenon is more serious

Comment 7

[liangxin]

Hi,everyone.Is there any advance?

Comment 8

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Jason -

This issue will happen when you pre-load some high resolution wallpapers(400x800 or 540 x960) in the device. As you can see from the attached video, the performance is quite bad. Since we have some qHD device later this year, I think it is worth checking this bug. 

Could you help to NI correct owner to check first?

Thanks

Comment 9

[Jason Smith [:jsmith]]

The video makes me think this is a graphics bug.

Milan - What do you think?

Comment 10

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

This is 1.3? Which one is Sora? What version of Android is under the covers? Does this reproduce on Hamachi/Buri?

Comment 11

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Milan Sreckovic [:milan] from comment #10)
> This is 1.3? Which one is Sora? What version of Android is under the covers?
> Does this reproduce on Hamachi/Buri?

Yes this is 1.3, and Sora(Fire C) is a device from TCL. It is of QCT 8210 platform. The android version is JB, Since the display of Sora is qHD, it will have several preload qHD wallpapers. I haven't tested this issue on Buri, will try it later

Thanks

Vance

Comment 12

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

Great - if this doesn't reproduce on Buri, we will need access to the device - we don't have any.  JB+1.3 is not the stablest of combinations. Also, these wallpapers are jpg? Do they have embedded thumbnails?

Comment 13

[liangxin]

This issue can be reproduce on foxphone,and wallpaper flicker more serious than on fire E.

Comment 14

[liangxin]

This issue can be reproduce on Ｆoxfone Ｏne,and wallpaper flicker more serious than on fire E.

Comment 15

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Foxphone One is Flame. Also attached please find the wallpaper TCL is using, just preload these wallpapers to Flame and you should be able to reproduce this issue

Thanks!

Comment 16

[Jason Smith [:jsmith]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> Foxphone One is Flame. Also attached please find the wallpaper TCL is using,
> just preload these wallpapers to Flame and you should be able to reproduce
> this issue
> 
> Thanks!

The flame bug is a different problem than this. See bug 1011460.

Comment 17

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Jason Smith [:jsmith] from comment #16)
> (In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> > Foxphone One is Flame. Also attached please find the wallpaper TCL is using,
> > just preload these wallpapers to Flame and you should be able to reproduce
> > this issue
> > 
> > Thanks!
> 
> The flame bug is a different problem than this. See bug 1011460.

Hum but 1011460 and 1008026 look quite the same to me, both issue mentioned that the wallpaper picker screen will flicker when you scroll up and down.

Anyway since we already have a video for 1008026, lets see if we can also have a video for 1011460, then we can know for sure if they are the same issue.

Thanks!

Comment 18

[Jason Smith [:jsmith]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #17)
> (In reply to Jason Smith [:jsmith] from comment #16)
> > (In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> > > Foxphone One is Flame. Also attached please find the wallpaper TCL is using,
> > > just preload these wallpapers to Flame and you should be able to reproduce
> > > this issue
> > > 
> > > Thanks!
> > 
> > The flame bug is a different problem than this. See bug 1011460.
> 
> Hum but 1011460 and 1008026 look quite the same to me, both issue mentioned
> that the wallpaper picker screen will flicker when you scroll up and down.
> 
> Anyway since we already have a video for 1008026, lets see if we can also
> have a video for 1011460, then we can know for sure if they are the same
> issue.
> 
> Thanks!

bug 1011460 doesn't occur on scrolling. It occurs just by loading up the wallpaper app & virtually everything disappears except one image. That's why these two bugs are different.

Comment 19

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Attachment: link to the wallpaper to reproduce this issue

Comment 20

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

It's good that this reproduces on Flame, but we're talking about 1.3 version here, which Flame was never meant to run on. What's the status on 1.4 or 2.0? We hardly have Flame going on 2.0.

Comment 21

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Milan Sreckovic [:milan] from comment #20)
> It's good that this reproduces on Flame, but we're talking about 1.3 version
> here, which Flame was never meant to run on. What's the status on 1.4 or
> 2.0? We hardly have Flame going on 2.0.

Hi Milan, i understand 1.3+JB is not the best combination, but our partner do have a product that will ship with 1.3+JB software, so i am wondering, is there anyway we can help our partner on this issue?

Thanks

Comment 22

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

The best start is probably to get access to a device.  Is there one close to Taipei or Toronto?

Comment 23

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Milan Sreckovic [:milan] from comment #22)
> The best start is probably to get access to a device.  Is there one close to
> Taipei or Toronto?

There are about 5 devices in TPE, so there is no Flame in Toronto?

Comment 24

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

Yes, we have Flames.  However, we hardly have a 2.0 Flame build, getting a 1.3 build for it would be a completely wasted effort, if we could even get there. Since we're talking about Sora device needing to go out on 1.3 (Flame does not), then Sora device would be the one to work on.

Comment 25

[Sotaro Ikeda [:sotaro]]

b2g v1.3 branch does not have a manifest xml for the flame device.
https://github.com/mozilla-b2g/b2g-manifest/tree/v1.3

Comment 26

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Sotaro Ikeda [:sotaro] from comment #25)
> b2g v1.3 branch does not have a manifest xml for the flame device.
> https://github.com/mozilla-b2g/b2g-manifest/tree/v1.3

Hi Sotaro, sorry, now the way we do it is just to flash the 1.3 image T2M provide for Flame:

https://mozilla.app.box.com/s/v87dfnez9q4bh4g78pb5/1/1708478428/16907200239/1

And then you can just download the wallpapers from the attached link, and build a 1.3 Gaia with these wallpaper as preload wallpapers, then you should be able to reproduce this issue after flashing the gaia

Thanks

Comment 27

[Sotaro Ikeda [:sotaro]]

This bug might be dup of bug 1006164.

Comment 28

[liangxin]

Hi,everyone.Is there any advance?

Comment 29

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

It may be possible to deal with this in Taipei, but the graphics team doesn't have the Sora device, and putting 1.3 on the Flame seems to be a hack.

Comment 30

[liangxin]

Hi,everyone.Please deal with this issue as soon as possible.

Comment 31

[liangxin]

Hi,Could you resolve this issue as soon as possible?

Comment 32

[Sotaro Ikeda [:sotaro]]

I've heard that Christopher Lee is going to send me Sora device.

Comment 33

[Jason Smith [:jsmith]]

Vance - Can you find out if this is a cert blocker?

Comment 34

[Preeti Raghunath(:Preeti)]

Please review if this one is an IOT oe cert blocker?

Comment 35

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

This is a cert blocker. Also in fact, the information is not correct in the issue description. This issue happened on Midori, not Sora.

Comment 36

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Sotaro Ikeda [:sotaro] from comment #32)
> I've heard that Christopher Lee is going to send me Sora device.

Hi Sotaro, since this one actually happen on Midori device, I will send you a Midori device from TPE office tomrrow.

In the meantime, since I get some Midori with me right now, maybe I can help to get the logs or any other information you need to start to work on this issue. Please just ni me if you need anything 

Thanks

Vance

Comment 37

[Sotaro Ikeda [:sotaro]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #36)
> (In reply to Sotaro Ikeda [:sotaro] from comment #32)
> > I've heard that Christopher Lee is going to send me Sora device.
> 
> Hi Sotaro, since this one actually happen on Midori device, I will send you
> a Midori device from TPE office tomrrow.

Thanks for the offer. Can I build Midori ROM by myself? The following manifest does not have configuration for Midori device.

https://github.com/mozilla-b2g/b2g-manifest

Comment 38

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

CJ, since we have a device in Taipei, can you have somebody look at this issue as well?

Comment 39

[u459114]

Sure, we will

Comment 40

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Jerry -

If you need Midori device, just let me know, I will bring one to your seat

Thanks

Vance

Comment 41

[Jerry Shih[:jerry] (UTC+8) (inactive)]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #40)
> Hi Jerry -
> 
> If you need Midori device, just let me know, I will bring one to your seat
> 
> Thanks
> 
> Vance

Yes, I need the device.
THX~

Comment 42

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Attachment: test for wallpaper flickering issue

I can reproduce this issue at nexus4 with gecko central and gaia master.
And I also can reproduce that at flame with gecko 1.4 and gaia 1.4.
The most important thing is that the wallpaper's size is 540*960.

I create this patch for debugging at master. This patch includes the test image. Just apply at gaia master and do "make reset-gaia".

I will check What happened to this larger size.

Comment 43

[Jerry Shih[:jerry] (UTC+8) (inactive)]

I have 40 test image in wallpaper, and I see a lot of ImageDecoder function in my profile data(more than 40 function call for ImageDecoder). Maybe we have a limit size of backgroundImage(wallpaper use css backgroudImage to display image) and we always need to decode the new image and throw out the old image when scrolling.
I will check the backgroundImage related code in b2g.

Comment 44

[Sotaro Ikeda [:sotaro]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #36)
> (In reply to Sotaro Ikeda [:sotaro] from comment #32)
> > I've heard that Christopher Lee is going to send me Sora device.
> 
> Hi Sotaro, since this one actually happen on Midori device, I will send you
> a Midori device from TPE office tomrrow.

Hi vchen, this bug is already taken by jerry.

Comment 45

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Please see bug 993825.

We have a limit size for image buffer. The flickering is because of we hit the limit size.
So b2g will kick some image out, but these kicked images maybe still are visible.
Thus, b2g decode these images again and then keep kicking another image.

The wallpaper app use "full" size image, it costs a lot of memory.
https://github.com/mozilla-b2g/gaia/blob/v1.3/apps/wallpaper/js/pick.js#L32
For small chage purpose, I think we should change the wallpaper implementation to display the thumbnail instead of the full size wallpaper.

David, What do you think?

Comment 46

[David Flanagan [:djf]]

See bug 1011460 for the 1.4+ version of this bug. In that case we are fixing it with #-moz-samplesize, which is a lot easier than manually creating a thumbnail for each wallpaper.  I don't think you can use #-moz-samplesize in 1.3, but there may be an earlier version of the patch attached to 1011460 that you could use to solve this bug.

Needinfo Punam so that she is aware that this bug is affecting 1.3 as well.  

Punam, if your earlier version of the patch fixes this 1.3+ bug, please share it with Jerry.  Or, if you can duplicate the bug in 1.3 on your Flame, maybe you can just take this bug from Jerry.

Comment 47

[Punam Dahiya [:pdahiya]]

(In reply to David Flanagan [:djf] from comment #46)
> See bug 1011460 for the 1.4+ version of this bug. In that case we are fixing
> it with #-moz-samplesize, which is a lot easier than manually creating a
> thumbnail for each wallpaper.  I don't think you can use #-moz-samplesize in
> 1.3, but there may be an earlier version of the patch attached to 1011460
> that you could use to solve this bug.
> 
> Needinfo Punam so that she is aware that this bug is affecting 1.3 as well.  
> 
> Punam, if your earlier version of the patch fixes this 1.3+ bug, please
> share it with Jerry.  Or, if you can duplicate the bug in 1.3 on your Flame,
> maybe you can just take this bug from Jerry.

I checked Flame and Nexus4. Both have pvtbuilds from 1.4 and there isn't 1.3.

Here's the link to the  patch for resolving wall paper flickering without using #-moz-samplesize
https://github.com/mozilla-b2g/gaia/pull/19502 ,its based off 2.0 and might have minor merge conflicts on 1.3 . Please feel free to needinfo if there are any questions.

Comment 48

[liangxin]

I have tried to test patch with apps/wallpaper/js/pick.js modification,but not change those pictures in wallpaper. 
  https://github.com/mozilla-b2g/gaia/pull/19502 
The issue still exists. Wallpaper pictures are 540*960 pixels which are larger than pictures with 480*480 pixels in patch.

Comment 49

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Attachment: PR:use thumbnail instead of full size image in wallpaper app

rebase https://github.com/mozilla-b2g/gaia/pull/19502 to v1.3.
The thumbnail path is at "resources/320x480/thumbnails". These thumbnails size are 320x480. Maybe they can become smaller.

Comment 50

[Jerry Shih[:jerry] (UTC+8) (inactive)]

If we want to add more wallpaper, we should modify the resources/320x480/list.json, and put the thumbnail into resources/320x480/thumbnails folder with the same file name.

Comment 51

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

base on https://github.com/mozilla-b2g/gaia/pull/19502 patch.
Show thumbnail instead of the big size wallpaper for v1.3 gaia

Comment 52

[Jerry Shih[:jerry] (UTC+8) (inactive)]

With attachment 8433993 [details] [review], Could you test your real use case(540*960 image) again at Midori device?
You should generate your wallpaper thumbnail(maybe the size is 320x480 or even smaller) and put into the thumbnail folder manually.

Comment 53

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Hi liangxin,
I think you can help us to test attachment 8433993 [details] [review].

Comment 54

[liangxin]

(In reply to Jerry Shih[:jerry] from comment #53)
> Hi liangxin,
> I think you can help us to test attachment 8433993 [details] [review].

I can have a try.

Comment 55

[liangxin]

I have tried attachment 8433993 [details] [review],select wallpaper use thumbnail picture with 320*480 pixels. Pick wallpaper use  pictures with 480*800 pixels in resources/320X480 directory with same name as thumbnail picture.
The flicker issue does not appear.

Comment 56

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Thanks, liangxin.
You can use your own thumbnail size and change the image folder for your larger wallpaper(by change the pick.js and list.jason).

Comment 57

[David Flanagan [:djf]]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

If this patch is for a Midori qHD device, the screen device pixel resolution is 540x960, right? Since we display three wallpapers per row, I think the thumbnails only need to be 180px wide. And to match the aspect ratio of the target screen, they should be 320px high.

It is probably not right to just use the 320x480 images as the thumbnails if we're using 480x800 or higher resolution wallpapers for the device. The thumbnails ought to match the actual wallpaper. So the right way to do this, is to copy all of the image files in resources/320x480 to resources/320x480/thumbnails and then reduce the size of all of those images to be 1/3rd of full size. Then we'll always get the @1.5x or @2x or whatever thumbnail matches the wallpaper that is being used.

Note that this patch is kind of brittle. If someone adds a new wallpaper to the main directory and list.json but does not add a thumbnail, the wallpaper will not show up. It would be better to modify the code so that if no thumbnail image is found, we would fall-back on the full-size image.  But since this patch is for 1.3 only and we have a better solution for 1.3T and beyond, I don't feel like you need to make that change. As long as our partners understand that they now have to define both a fullsize image and a thumbnail.

(If you do want to make the patch more robust, create an offscreen image and load the image into that at the same time that you set backgroundImage. If you get onload on the offscreen image, just discard the image. But if you get onerror, then no thumbnail exists and you should switch the backgroundImage to the original full-size wallpaper.)

This is an urgent last-minute fix that we've got to get landed, so r+ as long as you fix the images in the thumbnails/ directory as described above.

Comment 58

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

Thanks, David.
I add all 1/3 size image into thumbnail folder and update the PR.

Comment 59

[Jerry Shih[:jerry] (UTC+8) (inactive)]

This's an urgent fix, and our partner knows that they have to put both a fullsize image and a 1/3 size thumbnail.

Comment 60

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

update for test case.

David, could you please check the test case change for this modification?

Comment 61

[David Flanagan [:djf]]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

The test is failing because it is expecting a URL with no leading slash, but the change to the wallpaper app adds a leading slash before "/resources". So either modify the test to expect the leading slash or remove the leading slash in the app code.

When you do that and the test passes, feel free to land without further review.

Note that this patch will make the build size larger by a megabyte or two, so if there are devices where we are close to the maximum size limit for OTA updates should probably not take this update.

Also note that the resources/320x480/ directory is a mess. There are 1x and 1.5x images in the directory that do not appear in the list.json file. And there are items in the list.json file that do not have a 2x image.  If we're worried the size of the build, deleting the unused wallpapers would be a good place to start.

Comment 62

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

(In reply to David Flanagan [:djf] from comment #61)
> ...
> 
> Note that this patch will make the build size larger by a megabyte or two,
> so if there are devices where we are close to the maximum size limit for OTA
> updates should probably not take this update.

Preeti, it feels like this is useful information for the partners, and I'm sure you know who the right people are to get this info; can you pass it on?

Comment 63

[John Hu [:johnhu][:johu][:醬糊小弟]]

Since Jerry is OOO in these three days, he asked me to fix the "/" issue for him. The PR has been updated and unit tests of wallpaper are passed.

But the travis is still failed on a contact's unit test which is not related to this patch.

I found the following commit also failed at the same unit test.
https://travis-ci.org/mozilla-b2g/gaia/jobs/27380276
https://travis-ci.org/mozilla-b2g/gaia/jobs/27342820
https://travis-ci.org/mozilla-b2g/gaia/jobs/27248104

I will land the code and file another issue to track the failure of unit test.

Comment 64

[John Hu [:johnhu][:johu][:醬糊小弟]]

merged to master:
https://github.com/mozilla-b2g/gaia/commit/8d6bd6c484557c5322bf14798a4273d2a8f4300f

Comment 65

[Ryan VanderMeulen [:RyanVM]]

Please nominate this patch for Gaia v1.3 approval as soon as you feel it's sufficiently baked.

Comment 66

[Ryan VanderMeulen [:RyanVM]]

Err, comment 64 *was* to v1.3, not master. I don't see approval in this bug anywhere? What about every other branch after v1.3?

Comment 67

[Jason Smith [:jsmith]]

Tim - Can you work with John here to fix the landing? We should have landed on master first, asked for 1.3 approval, then land on 1.3 when approval is granted.

Comment 68

[Ryan VanderMeulen [:RyanVM]]

And v1.4/v2.0 assuming they're also affected.

Comment 69

[Punam Dahiya [:pdahiya]]

Attached reviewed patch - attachment 8433993 [details] [review]  is 1.3 only and should not have landed on master or in 1.4/2.0 - See #comment 46. NI David to keep him in the loop. Thanks

Comment 70

[Punam Dahiya [:pdahiya]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #66)
> Err, comment 64 *was* to v1.3, not master. I don't see approval in this bug
> anywhere? What about every other branch after v1.3?

just read and realised the commit is in v1.3 and not master which is good. We don't need this patch for any other branch. Thanks

Comment 71

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

(In reply to Jason Smith [:jsmith] from comment #67)
> Tim - Can you work with John here to fix the landing? We should have landed
> on master first, asked for 1.3 approval, then land on 1.3 when approval is
> granted.

This patch is v1.3 only and according to comment 70 it is not needed in other branches.

There is no bad landing here, just a unfortunate typo on comment 64.

Comment 72

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

Sorry, restore needinfo? [e-mail] from comment 62.

Comment 73

[Ryan VanderMeulen [:RyanVM]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #71)
> There is no bad landing here, just a unfortunate typo on comment 64.

Where was approval granted?

Comment 74

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

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #73)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #71)
> > There is no bad landing here, just a unfortunate typo on comment 64.
> 
> Where was approval granted?

Ouch, I guess I didn't pay enough attention to https://wiki.mozilla.org/Release_Management/B2G_Landing#v1.3.0 either .... sorry about it.

Jerry, could you set the approval flag on attachment 8433993 [details] [review] and fill the form?

Comment 75

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

sorry, I can't find the approval-gaia-v1.3? flag in this bug.
I just set approval-mozilla-b2g28? Does somebody can help me to set the correct flag?

This patch only for gaia v1.3.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): unknown. The vender use high quality wallpaper image in this bug.
User impact if declined: If we put large image resource(ex: 540*960 image) in wallpaper app, people will see the flickering when we scroll in wallpaper app. 
Risk to taking this patch (and alternatives if risky): Low. People need to remember to put the additional thumbnail at "resources/320x480/thumbnails" folder. The wallpaper app size will increase because of the additional thumbnail.
String or UUID changes made by this patch: no

Comment 76

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

sorry, I can't find the approval-gaia-v1.3? flag in this bug.
I just set approval-mozilla-b2g28? Does somebody can help me to set the correct flag?

This patch only for gaia v1.3.

[Approval Request Comment]
Bug caused by (feature/regressing bug #):  unknown. The vender use high quality wallpaper image in this bug.
User impact if declined:  If we put large image resource(ex: 540*960 image) in wallpaper app, people will see the flickering when we scroll in wallpaper app. 
Testing completed:  pass gaia test. See comment 63.
Risk to taking this patch (and alternatives if risky):  Low. People need to remember to put the additional thumbnail at "resources/320x480/thumbnails" folder. The wallpaper app size will increase because of the additional thumbnail.
String or UUID changes made by this patch:  no

Comment 77

[bhavana bajaj [:bajaj]]

Comment on attachment 8433993 [details] [review]
PR:use thumbnail instead of full size image in wallpaper app

gaia approval flag may be missing here due to the component. But a=bajaj for 1.3, might be a rubber stamp here since its already landed :-/, which was not correct!

Comment 78

[Preeti Raghunath(:Preeti)]

bajaj approved it.