Closed Bug 858883 Opened 13 years ago Closed 8 years ago

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

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::Gallery
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:-, b2g18+)

Status:
RESOLVED WONTFIX
Project Flags:
blocking-b2g -
Tracking Flags:
Tracking Status
b2g18 + ---

People

(Reporter: jhammink, Unassigned)

References

Details

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?
Blocks: 858886
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.
Oh, sorry. I see that 858886 is a new bug, not the old one that has been fixed.
Flags: in-moztrap?
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.