Closed Bug 1177374 Opened 9 years ago Closed 8 years ago

downloaded image not showing in picture library until reboot

Categories

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

defect
Not set
normal

Tracking

(b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-master --- affected

People

(Reporter: jya, Assigned: dhylands)

References

Details

(Keywords: foxfood, Whiteboard: [bzlite], [spark])

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Open Firefox, travel to a web site and download a photo. 
Wait for the notification stating that the download has completed. 

Now go into the photo library application. You would expect to see the downloaded photos there. But they are not showing. 

Now reboot the phone. Go into photo library: the image you've downloaded earlier is now showing. 

Expected results: image appear in photo library upon successful download.
QA Whiteboard: [foxfood-triaged]
QAWanted : could you see if this is happening with the downloads?  It's possible regression as dhylands recalls fixing this issue in general.
This issue seems irrelevant to Downloads. I can view the downloaded images via notifications or via Settings > Downloads. The issue is in Gallery not refreshing to detect newly downloaded images.

The issue is reproducible on Aries, and it's Aries only and doesn't happen on Flame (similar to bug 1161942 where reporter claims it's Nexus 5 only). Note that I set Flame to use 512MB memory so it doesn't LMK on me when I try to repro.

STR:
1) Have Gallery opened in the background
2) Open Browser, go to google.com
3) Long tap on the Google logo and save the image
4) Go back to Gallery

Gallery is not automatically refreshed to show the newly downloaded image.

Workaround: Kill the Gallery app and re-open it. A reboot is not needed.

Repro rate: 5/5

Device: Aries (RC4 > OTA'ed)
BuildID: 20150701171852
Gaia: 26b853b7cf94ea9e9ac6f20c55db462bd213a959
Gecko: ca0fd580a9ce
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5 Master) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

NI reporter to confirm my findings, specifically on what device they used, since it's not mentioned anywhere.
QA Whiteboard: [foxfood-triaged] → [foxfood-triaged][QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: needinfo?(jyavenard)
Keywords: qawanted
Whiteboard: [bzlite] → [bzlite], [spark]
QA Whiteboard: [foxfood-triaged][QAnalyst-Triage?] → [foxfood-triaged][QAnalyst-Triage+]
Flags: needinfo?(ktucker)
I'm not sure what the Aries phone is, I supposed it's the phone handled at Whistler. If so then yes, that's what I have.

And yes, the issue is with the gallery app
Flags: needinfo?(jyavenard)
Component: Gaia::Feedback → Gaia::Gallery
See Also: → 1191731
See Also: → 1194513
I'm suspecting this could be a dupe of Bug 1191731, :djf, what do you think?
Flags: needinfo?(dflanagan)
No-Jun: It might be dupe, or it might not.  Let's ask...

Dave or Andrew: have there been recent device storage changes that could have broken the integration between the download manager and device storage? Download manager needs to be able to somehow trigger device storage change events when it saves a new file to the device. (I'm assuming that it is doing this in gecko and not using the device storage api directly.)

Are this bug and bug 1191731 both the same bug in device storage?  Or are they separate bugs in the camera app and the download manager code?

And most importantly, is either of you the right person to take this bug?
Flags: needinfo?(dhylands)
Flags: needinfo?(dflanagan)
Flags: needinfo?(aosmond)
I'll take the bug and see if I can figure out what's going on.
Assignee: nobody → dhylands
Flags: needinfo?(dhylands)
Flags: needinfo?(aosmond)
nsVolumeService::GetVolumeByPath calls realpath on the provided filename (so that we resolve out symlinks).

This patch changes the 2 methods which set the mount point to also call realpath so that if the path passed in contains symlinks it will also resolve those to a non-symlinked path.
Attachment #8674009 - Flags: review?(alchen)
Attachment #8674009 - Flags: review?(alchen) → review+
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.

Attachment

General

Created:
Updated:
Size: