Closed
Bug 1177374
Opened 10 years ago
Closed 8 years ago
downloaded image not showing in picture library until reboot
Categories
(Firefox OS Graveyard :: Gaia::Gallery, defect)
Firefox OS Graveyard
Gaia::Gallery
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)
3.30 KB,
patch
|
alchen
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•10 years ago
|
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.
Comment 2•10 years ago
|
||
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?]
status-b2g-master:
--- → affected
Flags: needinfo?(ktucker)
Flags: needinfo?(jyavenard)
Keywords: qawanted
Whiteboard: [bzlite] → [bzlite], [spark]
Updated•10 years ago
|
QA Whiteboard: [foxfood-triaged][QAnalyst-Triage?] → [foxfood-triaged][QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Reporter | ||
Comment 3•10 years ago
|
||
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)
Updated•10 years ago
|
Component: Gaia::Feedback → Gaia::Gallery
Comment 4•9 years ago
|
||
I'm suspecting this could be a dupe of Bug 1191731, :djf, what do you think?
Flags: needinfo?(dflanagan)
Comment 5•9 years ago
|
||
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)
Assignee | ||
Comment 6•9 years ago
|
||
I'll take the bug and see if I can figure out what's going on.
Assignee: nobody → dhylands
Flags: needinfo?(dhylands)
Updated•9 years ago
|
Flags: needinfo?(aosmond)
Assignee | ||
Comment 7•9 years ago
|
||
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)
Updated•9 years ago
|
Attachment #8674009 -
Flags: review?(alchen) → review+
You need to log in
before you can comment on or make changes to this bug.
Description
•