Closed Bug 1055805 Opened 6 years ago Closed 6 years ago

[Gallery] If the user tries to set the wallpaper with an image 3.8 mb or greater, the gallery app will close

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.4+, b2g-v1.4 wontfix, b2g-v2.0 wontfix, b2g-v2.1 fixed, b2g-v2.2 verified)

RESOLVED FIXED
2.1 S4 (12sep)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- wontfix
b2g-v2.0 --- wontfix
b2g-v2.1 --- fixed
b2g-v2.2 --- verified

People

(Reporter: dharris, Assigned: djf)

References

()

Details

(Keywords: regression, Whiteboard: [2.1-flame-test-run-1])

Attachments

(9 files)

Attached file Gallery Closing.txt
Description:
When the user oepns a 3.8mb image in gallery, then tries to share the image out to the wallpaper, the Gallery app will be LMK'd and the wallpaper will not be set

Prerequisite: Have an image that is 3.8mb or greater on DUT

Repro Steps:
1) Update a Flame to 20140818040201
2) Open Gallery App
3) Select Image 3.8mb or greater
4) Tap on share Icon> Wallpaper


Actual:
Image will not load and "set as wallpaper" will not function. The app will close from LMK after a short time


Expected:
Image is loaded and the user is able to crop the image before setting the image as a wallpaper

Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140818040201
Gaia: aa8aace12d65956dd9525da5dac66e0d3b28597f
Gecko: 0aaa2d3d15cc
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Keywords: Gallery, Wallpaper, Share, OOM, Low Memory Kill, Crash, Close, Dissapear, Save, Background

Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/3637/
See attached: Logcat, Video - http://youtu.be/QiOZl9geJKQ
This issue DOES repro on Flame 2.0 (319mb), Flame 1.4 (319mb)

When opening an image that is 3.8mb or greater, the Gallery app will close from LMK

Flame 2.0

Environmental Variables:
Device: Flame 2.0 (319mb)
BuildID: 20140818000201
Gaia: fb2dd31abed2803eb7ad67eb4c52abb48de1e0f7
Gecko: 09f7a7184c71
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Flame 1.4

Environmental Variables:
Device: Flame 1.4 (319mb)
Build ID: 20140818063007
Gaia: 21bec64497dc06a7f12071d573570ba8fea598ae
Gecko: 07d78d0f9bef
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
_______________________________________________________________________________________

This issue DOES repro on Buri 2.1, Buri 2.0, and Buri 1.4

When opening an image that is 3.8mb or greater the  image will not load then if the user taps on "set as wallpaper", the Gallery app will close from LMK

Buri 2.1

Environmental Variables:
Device: Buri 2.1 Master
BuildID: 20140818073016
Gaia: ba1992f2addc5a84afc2eab426f222a6bf2962ba
Gecko: bf27e27c994d
Version: 34.0a1 (2.1 Master)
Firmware: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140818063008
Gaia: 640ce38ca03f1e26a4524ff4215b8b3f7731e2f0
Gecko: 692c93509dc9
Version: 32.0 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Buri 1.4

Environmental Variables:
Device: Buri 1.4
BuildID: 20140818063007
Gaia: 21bec64497dc06a7f12071d573570ba8fea598ae
Gecko: 07d78d0f9bef
Version: 30.0 (1.4)
Firmware: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
This issue DOES repro on Flame 2.1 (512)

When opening an image that is 3.8mb or greater the  image will not load then if the user taps on "set as wallpaper", the Gallery app will close from LMK

Environmental Variables:
Device: Flame Master (512mb)
Build ID: 20140818040201
Gaia: aa8aace12d65956dd9525da5dac66e0d3b28597f
Gecko: 0aaa2d3d15cc
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Summary: [B2G][Gallery] If the user tries to set the wallpaper with an image 3.8 mb or greater, the gallery app will crash → [B2G][Gallery] If the user tries to set the wallpaper with an image 3.8 mb or greater, the gallery app will close
Can you try to reproduce this again on the latest builds?
Flags: needinfo?(ktucker) → needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Attached image Drawing.jpg
Attached the image used to run into this issue


This issue is still occuring on the latest Flame 2.1

Opening an image that is 3.8mb or great will cause the gallery to close from LMK

Flame 2.1

Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140822040202
Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28
Gecko: 0b9dd32d1e16
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
_________________________________________________________________________________

This issue is NOT happening on Flame 2.0

The image will not load on the device but if the user taps on "set as wallpaper" the image will be set. However the user is not able to crop the image, due to not being able to view it.

Flame 2.0

Environmental Variables:
Device: Flame 2.0 (319mb)
Build ID: 20140822000206
Gaia: 64b0c0ae60fdeac953a7e2a3c368d124bf848477
Gecko: 5075528d7241
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(dharris) → needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
So this issue is occurring on the latest Flame 2.1(319mb) build but is no occurring on the latest 2.0(319mb)build? Please update the tracking flag accordingly and add the regression keyword. Can you check 1.4 again and remove [B2G] from your title?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(dharris)
This issue is NOT happening on Flame 1.4 (319mb)

The image will not load on the device but if the user taps on "set as wallpaper" the image will be set. However the user is not able to crop the image, due to not being able to view it. This issue seems to be outlined in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=883028

Flame 1.4

Environmental Variables:
Device: Flame 1.4 (319mb)
BuildID: 20140825063013
Gaia: cf9d74da6653efeb43d9653e81c61aa00e693a67
Gecko: cdcb73d0febc
Version: 30.0 (1.4)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regression
Summary: [B2G][Gallery] If the user tries to set the wallpaper with an image 3.8 mb or greater, the gallery app will close → [Gallery] If the user tries to set the wallpaper with an image 3.8 mb or greater, the gallery app will close
Flags: needinfo?(dharris) → needinfo?
[Blocking Requested - why for this release]:

From an end user's perspective this would be frustrating and they will have no idea what is causing the LMK. This is a regression so nominating 2.1?
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: needinfo?
Repro rate is too low on latest 2.1 Flame to find a regression window.

Observed behavior: The set wallpaper screen does not load the image (attached on comment 4), but if I keep tapping on 'Set' button, after about 30 seconds I'm being returned to previous screen in Gallery and the wallpaper is correctly set. LMK was only observed 1/7 attempts.

Tested on:
Device: Flame (319MB mem)
BuildID: 20140825172052
Gaia: 4d1d0ea5a82cddeeab497774cfa1703639e3c7d9
Gecko: dc352a7bf234
Version: 34.0a1 (2.1 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
I agree; after speaking with the reporter and QA-Wanted tester this bug has a variable (but mostly LOW) repro rate. A Window here would be more problematic and time-consuming than it would be worth.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Do we need further analyze this and get to the root cause?
Ni Mike
Flags: needinfo?(mhabicher)
Based on earlier comments, it sounds like we're running out of memory. The attached image (3435x2363px) would decompress to almost 31MB! djf might have some ideas on how to mitigate this issue when he gets back.
Flags: needinfo?(mhabicher) → needinfo?(dflanagan)
The wallpaper app was never updated to use the downsample-while-decoding capability of the #-moz-samplesize media fragment. So now the gallery app can display images larger than the wallpaper app can handle, which is what is causing this bug.

The fix is to modify the wallpaper to use the the features of shared/js/image_utils.js so that large images like the one attached to this bug are downsampled before being displayed.

I should have updated the Wallpaper app to match the changes in the Gallery app, so I'm taking this bug.
Assignee: nobody → dflanagan
Flags: needinfo?(dflanagan)
Another contributing factor here is that the sample image attached to this bug is a progressive jpeg rather than a regular jpeg, which causes more memory use overall.  

Bug 1046167 just landed on 8/27 and prevents pjpegs of this size from being displayed in the gallery at all.  So this bug should no longer reproduce on master or in 2.1 because the test image won't even appear in the gallery app.

Still, we should fix it:

- in the wallpaper app so that we downsample wallpaper while decoding it

- possibly by uplifting the pjpeg fix to other releases so we don't get into memory trouble in 2.0.

Also, for any QA people listening: the file size of a jpeg file has almost nothing to do with anything. What matters is the number of pixels in the image.  This one is a 7 or 8 megapixel image which is pretty big. And because it is a pjpeg it uses extra memory. But the size of the file is basically irrelevant.
I have a patch for the wallpaper app, but now I have to create myself a different test image for it since the attached one no longer works because of bug 1046167
Triage on 9/3:

Blocking Decision: Non Blocking; Repro rate is low per previous comments and happens with images that are more than 7 or 8mp per David's comments. 

David is working on a fix and if it is wrapped up in this sprint and does not add risk to 2.1, we can request for uplift approval from 2.1 sheriffs (fabrice/bhavana)

Thanks
Hema
blocking-b2g: 2.1? → ---
Target Milestone: --- → 2.1 S4 (12sep)
This is the same image, converted from progressive jpeg to regular jpeg, enlarged even more, and then saved at really low quality. I can reproduce the bug with this image on master.
Punam,

This patch handles the share activity case for setting wallpaper. It adds code to downsample jpeg files before displaying and prevents OOM errors. Note that it uses the new self-contained shared/js/image_utils.js library instead of shared/js/media/image_size.js and shared/js/media/downsample.js
Attachment #8484607 - Flags: review?(pdahiya)
Comment on attachment 8484607 [details] [review]
link to patch on github

Hi David
Thanks for the patch, it looks good and has my r+. While testing on flame, in latest m-c build without patch, I see  a bug where after share and set wallpaper from gallery, wallpaper on home screen doesn't change even though under settings -> Display, new wallpaper is updated.  This is a different bug and possibly related to bug 1061724. Thanks
Attachment #8484607 - Flags: review?(pdahiya) → review+
Landed on master: https://github.com/mozilla-b2g/gaia/commit/16e519daad9ecf58e6b2cdc78645f0eb711c3c8c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Comment on attachment 8484607 [details] [review]
link to patch on github

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):

In 1.4 and later, the Gallery app can handle really big jpeg images by downsampling them as needed to prevent OOMs. When I landed those changes, I forgot to do the same thing in the wallpaper app, so it is now possible for the user to preview a monster jpeg image in gallery and try to set it as wallpaper, and this can cause OOM errors when the wallpaper app decodes it at fullsize.

[User impact] if declined:

Sharing large jpeg images as wallpaper may fail

[Testing completed]: on master

[Risk to taking this patch] (and alternatives if risky):

This is not a trivial patch, but not a particularly complex or risky one. I think that 1.4 and 2.0 are affected by this bug but feel like this patch would be too risky to uplift to those releases. It is still early enough in the 2.1 stabilization period, however, that I think it is worth the small risk to uplift this to 2.1.

[String changes made]: none
Attachment #8484607 - Flags: approval-gaia-v2.1?(fabrice)
This bug does affect 1.4 and 2.0, so setting those flags back to affected. I'm not suggesting that we uplift to those releases, however.
Attachment #8484607 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Attached file patch for v1.4
Hi Vance,
This patch is for v1.4. 
I just verified it can resolve bug 1069822, so if you want to land it please let me know.
Thanks.
Flags: needinfo?(vchen)
Attached file patch for v2.0
This patch is for v2.0.
If someone need this patch feel free to land it.

Thnaks.
(In reply to GaryChen [:GaryChen][:PYChen][:陳柏宇] from comment #23)
> Created attachment 8500882 [details] [review]
> patch for v1.4
> 
> Hi Vance,
> This patch is for v1.4. 
> I just verified it can resolve bug 1069822, so if you want to land it please
> let me know.
> Thanks.

Thanks Gary, let's land it on v1.4!

Vance
blocking-b2g: --- → 1.4+
Flags: needinfo?(vchen)
Needs Gaia v1.4 approval before it can be uplifted. Same for v2.0.
Flags: needinfo?(dflanagan)
Comment on attachment 8500882 [details] [review]
patch for v1.4


[Approval Request Comment] See comment #20. This has been stable on master and 2.1 for almost a month now, so I now think the risk of uplift to earlier releases is less.

Vance wants it in 1.4, so I suspect that uplift approval is mostly a formality at this point.

I'm also going to request uplift of the other PR to 2.0 because it seems silly to have this in 1.4 and 2.1 but skip 2.0.
Attachment #8500882 - Flags: approval-gaia-v2.0?
Attachment #8500882 - Flags: approval-gaia-v1.4?(bbajaj)
Flags: needinfo?(dflanagan)
Attachment #8500883 - Flags: approval-gaia-v2.0?(bbajaj)
Vance: I've set the appropriate flags to request uplift, per Ryan's reminder.
Flags: needinfo?(vchen)
Attachment #8500882 - Flags: approval-gaia-v2.0?
Vance, reading through all the comments, I gather that the rate of reproducibility is low here and also don't feel too comfortable uplifting given comment #20/21.

Can you expand on why this is so critical ? have you heard end user reports on folks running into this or partner being able to reproduce easily?
Emailed vance to help here as I need his input in comment #30 before approving.
Sorry about the late response Bhavana. Per my understanding, this issue is 100% reproducible as you as you try to set a large image(large in terms of number of pixels in the image) as wallpaper. So if user copy some high resolution pictures to the phone via PC and try to set those pictures as wallpaper, he/she will encounter this issue.

However if it is just too risky to put it in 1.4/2.0, I agree to pull down the blocking flag. we can just ask partner(if they absolutely want this fix) to cherry-pick the patch, or just uplift it to device branch such as 2.0M...but again, that will somehow create further OS fragment

Thanks
Flags: needinfo?(vchen)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #32)
> Sorry about the late response Bhavana. Per my understanding, this issue is
> 100% reproducible as you as you try to set a large image(large in terms of
> number of pixels in the image) as wallpaper. So if user copy some high
> resolution pictures to the phone via PC and try to set those pictures as
> wallpaper, he/she will encounter this issue.
> 
> However if it is just too risky to put it in 1.4/2.0, I agree to pull down
> the blocking flag. we can just ask partner(if they absolutely want this fix)
> to cherry-pick the patch, or just uplift it to device branch such as
> 2.0M...but again, that will somehow create further OS fragment
> 
> Thanks

Vance, thanks for the input. I think we should be very cautious in making these blocking decisions here as we have folks who consider blockers to be fixed with highest priority which is the expectation. And if we do not end-up taking the patch, it is not be a win-win situation for any of us and wasted effort. So it will really help on making the not making a blocking call unless its is a show-stopper.

I'll clear the approval flag and leaving it to you to clear the blocking flag here as it was set in comment #26. Thanks!
Attachment #8500882 - Flags: approval-gaia-v1.4?(bbajaj) → approval-gaia-v1.4-
Attachment #8500883 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0-
Flags: needinfo?(vchen)
This bug has been verified to fail on Flame 2.1
Issue steps:
1) Open Gallery App
2) Select Image 3.8mb or greater
3) Tap on share Icon> Wallpaper
4) Tap Set button.
** The image will be loaded, but "set as wallpaper" will not function. The gallery app won't close.

See attachment: Verify_video_Flame_2.1.3gp and logcat_flame_2.1_1617.txt
Reproducing rate: 5/5
Flame2.1 build:
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0
Flags: needinfo?(hlu)
This issue has been verified successfully on Flame 2.2

See attachment: Verify_video_Flame_2.2.3gp
Reproducing rate: 0/5
Flame2.2 build:
Gaia-Rev        824a61cccec4c69be9a86ad5cb629a1f61fa142f
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/acde07cb4e4d
Build-ID        20141125040209
Version         36.0a1
Hi Paladin,
    Please file another bug to indicate this issue still happens on v2.1, and set see also to link this issue to new file bug. Thank you very much.
Flags: needinfo?(hlu) → needinfo?(jihao)
See Also: → 1106504
Flags: needinfo?(jihao)
You need to log in before you can comment on or make changes to this bug.