1074632 - [download] Saved image is not updated in gallery app if gallery app is already launched

Status: RESOLVED DUPLICATE of bug 1072535

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

Description

[jackjang]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:

STR.

1. Launch gallery app first(some pictures show preview)
2. Browser -> article view -> image long press -> saved image -> home key -> gallery 


Actual results:

New saved image doesn't appear in gallery app.


Expected results:

New saved image should be appeared in gallery app

Comment 1

[jackjang]

Gallery & all the media app (music, video) will listen to "oncreate" event triggered from mediaDb. MediaDb will internally uses devicestorage for sending create events. 
Since media apps wont get "oncreate" event.

Due to this gallery is not updated until its restarted.

It is reproduce Flame master version as well.

Comment 2

[[:mmc] Monica Chew (no longer reading bugmail)]

Sorry, I don't know who owns this code.

Comment 3

[Wayne Chang [:wchang]]

Hema,

Not sure if this falls under media but are we planning on changing the mechanism here?

Comment 4

[Hema Koka [:hema]]

(In reply to Wayne Chang [:wchang] from comment #3)
> Hema,
> 
> Not sure if this falls under media but are we planning on changing the
> mechanism here?

I can see how annoying this would be for the end-user. Not having to be able to see the image immediately on Gallery. 

David and Dave, What does it take to fix? 

Thanks
Hema

Comment 5

[Dave Hylands [:dhylands]]

It looks like the browser isn't using device storage to save the image. The media apps only see files saved via device storage.

Which begs the question, how is the browser determining where to save the attachments?

Comment 6

[Dave Hylands [:dhylands]]

Adding a needinfo for Ben Francis, since I think he probably knows about the browser.

Comment 7

[Ben Francis [:benfrancis]]

I do know a bit about the browser, but this is more to do with the download manager. The browser used to use DeviceStorage to store images in the images bucket by mapping file extensions to MIME types. Now it just triggers the download manager which takes care of everything.

Is this a regression?

Aus, do you know how the download manager stores files?

Comment 8

[Aus Lacroix [:aus]]

This is all done under the hood in Gecko now via JS Downloads + Downloads API. At that level, we actually need to provide a concrete path so that we can write to the file. There's no way for us to use the DeviceStorage API to accomplish the work that we want. We could however indicate to DeviceStorage that a new file was created without having to use DeviceStorage to write to it. We just need it to see the new file and generate the event to the listeners.

I also feel like this used to work... with those exact STRs. So it's a possible change in how we manage media overall on the device that could have regressed this.

Comment 9

[[:mmc] Monica Chew (no longer reading bugmail)]

Paolo owns the JS Downloads API.

Comment 10

[:Paolo Amadini]

(In reply to Ghislain Aus Lacroix [:aus] from comment #8)
> We could however indicate to DeviceStorage that a new file was created

With the JavaScript API for downloads, always executed in the parent process, new files can be detected using a view on the global DownloadList, observing when a download transitions to a success state. I don't know about the DOM Downloads code used in B2G, which operates in other processes as well.

Let me know if this answers the request for information, or you need more details on the API itself.

Comment 11

[Aus Lacroix [:aus]]

The issue isn't with the JS Downloads API nor is it with the Downloads API itself. I'm certain something has changed in how we scan for changes on the SD card now so I actually need to manually generate an event to the DeviceStorage API so it can signal it's listeners that a new file was created. 

This wasn't a requirement before, but it sure looks like it is now. :) Again, I don't think this is terribly difficult to accomplish but I would like to know if the issue is present in 2.1 (this would be gecko34 iirc) as it may warrant us blocking on this.

Comment 12

[jackjang]

[Blocking Requested - why for this release]:

Comment 13

[Safwan Rahman (:safwan)]

(In reply to Ghislain Aus Lacroix [:aus] from comment #11)
> The issue isn't with the JS Downloads API nor is it with the Downloads API
> itself. I'm certain something has changed in how we scan for changes on the
> SD card now so I actually need to manually generate an event to the
> DeviceStorage API so it can signal it's listeners that a new file was
> created. 
> 
> This wasn't a requirement before, but it sure looks like it is now. :)
> Again, I don't think this is terribly difficult to accomplish but I would
> like to know if the issue is present in 2.1 (this would be gecko34 iirc) as
> it may warrant us blocking on this.

It can be reproduced in V 2.1.

Environmental Variables:
Device: Keon V2.1
BuildID: 20140926113817
Version: 34.0a1

Comment 14

[Safwan Rahman (:safwan)]

Interesting fact is, while opening Gallery app, if you take a photo with the Camera, the gallery updated automatically. Also works fine while taking screenshot. 
Seems to be affected when try to download images from website.

Comment 15

[[:fabrice] Fabrice Desré]

I chatted with dhylands about that issue on irc, and we know what's going on. I'm assigning to Dave since he will likely work on the patch.

Comment 16

[Safwan Rahman (:safwan)]

It also can be reproduced in V2.0
Environmental Variables:
Device: Keon V2.0
BuildID: 20140925201526
Gaia: 95a5168
Gecko: 7116d52
Version: 34.0a1

It can not be reproduce in V1.4
Device: Keon V1.4
BuildID: 20141005021108
Gaia: b06fee1
Gecko: a4482c4
Version: 30.00

Comment 17

[Aus Lacroix [:aus]]

I'm not sure why I was NI'd on this. But yes, I think if this is affecting 2.0, 2.1 and 2.2 we should block *for all releases*

Comment 19

[Dave Hylands [:dhylands]]

(In reply to :Paolo Amadini from comment #10)
> (In reply to Ghislain Aus Lacroix [:aus] from comment #8)
> > We could however indicate to DeviceStorage that a new file was created
> 
> With the JavaScript API for downloads, always executed in the parent
> process, new files can be detected using a view on the global DownloadList,
> observing when a download transitions to a success state. I don't know about
> the DOM Downloads code used in B2G, which operates in other processes as
> well.
> 
> Let me know if this answers the request for information, or you need more
> details on the API itself.

So - fundamentally, I need to tell device storage that a new file was downloaded to one of the storage areas.

What I need to do is add something like the following:

> let pathString = Cc["@mozilla.org/supports-string;1"].createInstance(Ci.nsISupportsString);
> pathString.data = aDownload.path;
> Services.obs.notifyObservers(pathString, "download-watcher-notify", aEventType);

to the place in the code where the download has reached final destination (i.e. the .part file has been renamed/copied to it's final destination).

Comment 20

[Dave Hylands [:dhylands]]

Paolo,

If you could help me figure out where/how to plumb in the notification mentioned in comment 19, that would be great.

Comment 21

[howie [:howie]]

Triage: remove blocking nom, to track at 2.0+ blocker bug 1072535

Comment 22

[:Paolo Amadini]

(In reply to Dave Hylands [:dhylands] from comment #20)
> If you could help me figure out where/how to plumb in the notification
> mentioned in comment 19, that would be great.

Replied in bug 1072535. Thanks for providing a patch to start with!