856188 - [B2G] [Gallery] Gallery does NOT open from homescreen Wallpaper secondary menu.

Status: VERIFIED FIXED

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

Description

[mlevin]

Attachment: Gallery never fully loads

Description:
Gallery fails to fully open when trying to set a picture as a wallpaper accessed from "Wallpaper" choice after long press of Homescreen.

Prerequisite: Have many photos and videos in the Gallery.

Repro Steps:
1) Update to Unagi Build ID: 20130329070203 by MANUAL flash.
2) Go to Settings - Device Information - More Information - Reset Device in order initiate a reset.
3) After FTU long tap the Homescreen.
4) On the "Select from:" choose "Gallery".

Actual:
Only 2 photos appear, and the Gallery never fully loads.

Expected:
Gallery is fully loaded and shows all the thumbnails.

Environmental  Variables:
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/56c922308fd1
Gaia: 0a9f78bffafda93a159c1f502e8b110c2f49a500

Notes:
Repro frequency: 3/3
Q Analysts Test Team Priority: (Priority Levels: Pri 2)

If Gallery is opened from the Gallery icon, then the issue as followed by the steps above will not reproduce. User must reset the device to observe the issue without opening the Gallery from the Gallery icon first.

Attachment: Logcat

Comment 1

[mlevin]

Issue also reproduces when trying to open Gallery from the Add New Contact screen.

Comment 2

[Marcia Knous [:marcia]]

How many pictures do you have in your Gallery?

I have an SD card with a fair number of pictures and they seem to be loading, although not all of them seem to load.

Comment 3

[mlevin]

video of issue at http://youtu.be/BKOSoct8Xg0

NOTE: It appears issue only reproduces after an Unagi reset and when trying to access the Gallery for the 1st time via adding a new contact OR from the long tap of the Homescreen.

Comment 4

[David Flanagan [:djf]]

Taking this. I just landed a patch to the pick activity (bug 834773) and did not test it in the scanning case, so I bet I broke this.

My pick activity patch was uplifted to v1-train, so I'm guessing that it is broken there, too.  Nominating for Leo.

Setting QA wanted to find out which branches this is broken on. I know it is a smoketest failure, but I don't know if the smoketest was being done on master or a different branch.

QA: don't waste time looking for a regression range until you've first just tried backing out 834773.

Comment 5

[David Flanagan [:djf]]

The regression is actually older than I thought...

This bug occurs when there are photos and videos on the sdcard. When gallery is opened for a 'pick' activity, it only displays photos, not videos. And in that case, the metadata parser fails if it encounters a video.

This is almost certainly a regression from bug 837263  which was a massive patch to work around the fact that software decoding of H.263 videos has been disabled.

That patch landed on master on 2/16, and was uplifted to v1-train and v1.0.1. So I'm setting the appropriate 'affected' flags.

Comment 6

[David Flanagan [:djf]]

Attachment: link to patch on github

Dominic,

If you don't have time to review this, I can find someone else. But I think you're in the most advantageous timezone for my late-night bug fixes :-) (plus you know the metadata parsing stuff better than anyone else).

Setting needinfo on the reporter.  mlevin: could you try this patch and see if it fixes the issue you were seeing. This patch fixes the bug I found where scanning would never stop if there was a new video on the sdcard. But there is a chance that you were seeing a different bug.

Comment 7

[David Flanagan [:djf]]

Triage folks: this is a pretty simple fix that I think we should uplift at least to leo.

Comment 8

[David Flanagan [:djf]]

Dominic,

I just realized that from looking at the patch you might not know what the original bug was. Previously, when invoked for a pick activity, we were leaving the videostorage variable undefined (because we were not going to be displaying videos). But if there were video poster images on the sdcard, we still tried to parse the video metadata. And that process required videostorage to be defined. So we were throwing an exception from an async function somewhere and the metadata parser was stalling out and never finishing.

So the key part of this fix is just making sure that videostorage is always defined. The rest of it is just getting rid of function arguments that are not necessary anymore.

Comment 9

[Wayne Chang [:wchang]]

Triage 4/2 - setting leo+ per comment 5 and comment 7 to fix regression.

Comment 10

[Dominic Kuo [:dkuo]]

Comment on attachment 732673 [details]
link to patch on github

David,

Thanks for the description of this bug. Before applying this patch, I tried to test the pick activity with video files included in my sd card, and yes, there was an exception said "videostorage is undefined" from the metadata parser. After this patch is applied, I didn't get the same error again and the parser can successfully parsed all the images/videos.

And this patch looks good, we just always define the videostorage object, which is trivial and simple to fix this issue.

Comment 11

[David Flanagan [:djf]]

Landed in master: https://github.com/mozilla-b2g/gaia/commit/8894d2afac10aa7c67fc59ea14caad885ec31089

Comment 12

[David Flanagan [:djf]]

This isn't applying cleanly to v1-train, apparently because I did not uplift bug 834773, even though I marked it as fixed on v1-train!  I'll go fix that there first.

Comment 13

[David Flanagan [:djf]]

I had uplifted that bug, but part of the patch had been overwritten by another uplift. I've fixed it, and this patch now applies cleanly to v1-train.

Landed on v1-train: https://github.com/mozilla-b2g/gaia/commit/a845be046c5d3cb077e3c78f963ca5c079e7ab3d

Comment 14

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

At this point, seems like we've figured out what branches this affects. Is that qawanted still valid?

Comment 15

[David Flanagan [:djf]]

Sorry Geo, clearing all the QA flags.

Comment 16

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

No worries, just didn't want to drop something on the ground if it still needed action. Thanks!

Comment 17

[mlevin]

Verified fixed the ability to fully open Gallery from both Wallpaper AND within Contacts.

Tested on Unagi with:
Unagi Build ID: 20130404070202
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/da523063aa7b
Gaia: a845be046c5d3cb077e3c78f963ca5c079e7ab3d

Comment 18

[mdaniloff]

Verified fixed the ability to fully open Gallery from both contacts and wallpaper settings

Unagi V.1.0.1
Unagi Build ID: 20130404070204
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/e43e65ec89d2
Gaia: daea430624ec02f8d36a12d581fc4a3278c27cb7

Comment 19

[mlevin]

Issue reproduces on today's v101 build:

Build ID: 20130408075816
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3b51ced33215
Gaia: 8cf8dbd430af5e72a2ad542824421debe6de29d4

Issue: Gallery never fully opens when accessed for the first time from either Contact or from long tap of Homescreen.

Comment 20

[David Flanagan [:djf]]

(In reply to mlevin from comment #19)
> Issue reproduces on today's v101 build:

Yes, that's expected. That's why the status-b2g-v1.0.1 flag is set to 'affected'.

In order to get this fixed, the patch needs to be uplifted to v1.0.1.

The way to do that is not to re-open the bug, but to nominate it tef?.

Setting those flags now.

Comment 21

[David Flanagan [:djf]]

Landed on v1.0.1: https://github.com/mozilla-b2g/gaia/commit/5fb2ba41150ab5699f210cac9ee899bb0227a008

mlevin: this has now been uplifted. You can attempt to verify it again.

Comment 22

[David Flanagan [:djf]]

Oops, I meant to set that flag to fixed, not verified...

Comment 23

[mlevin]

Verified fixed the ability to fully open Gallery from both contacts and wallpaper settings.

Environmental  Variables:
Unagi Build ID: 20130410070204
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/935ff9a97f7b
Gaia: aff876b051c51d091cecf322b90c4f0093281b5e

Thank you David Flanagan.