[Gallery] Pictures are still being loaded "on the fly" several hours after phone is switched on

RESOLVED WONTFIX

Status

Product:
Firefox OS
Component:
Gaia::Gallery
RESOLVED WONTFIX
Reported:
5 years ago
Modified:
2 months ago

People

(Reporter: John Hammink, Unassigned)

Tracking

Version:
unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:-, b2g18+)

Details
(Reporter)

Description

•
5 years ago 
Tested on Unagi nightly, mozilla RIL 4/5
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/1d4c7fe3256e
Gaia   2f64311e0f23b85c29b20be9502cbdeaee8342ae
BuildID 20130405070205

STR:
 - open the gallery application with thousand of photos on the SD card (but not yet imported to gallery).
 - Do not scroll. Let the phone sit for > 1 hour while watching the gallery app.

Actual:
 - Images continue to "pop" into the view while the phone is idle.

Expected:
 - Without scrolling, images in the current view should not change.  As I understand it, only after scrolling down should one be able to observe more images loaded at the bottom.
Flags: in-moztrap?
 (Reporter)

Updated

•
5 years ago
Blocks: 858886

Comment 1

•
5 years ago 
Photos are processed in whatever order the device storage scanning API returns them.  And then they are displayed newest first. So if DeviceStorage returns the oldest ones first, then new photos will always appear at the top of the list.

The workaround would be to scan all the photos first, put them in order, and then process them in a separate step in the chronological order.  I can do that, but it would mean slowing down scanning in the normal case in order to get better behavior in this fairly pathalogical test case.

(I don't believe that actual users of this phone are going to load 1000s of photos and scan them all at once.  In normal use, there will be a few new photos taken with the camera app, and the gallery will find them and display them at the top and be done.  So I'm really not too concerned about this.)

Why is this bug marked as blocking 858886?  That bug is fixed: the app no longer crashes.  But scanning now takes *forever*.  There's a gecko patch that I'm hoping will get uplifted that will allow us to make scanning faster again, though.

Comment 2

•
5 years ago 
Oh, sorry. I see that 858886 is a new bug, not the old one that has been fixed.
 (Reporter)

Updated

•
5 years ago
Flags: in-moztrap?

Comment 3

•
2 months ago 
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.