859696 - [DeviceStorage] getEditable's result is not FileHandle object. Diff with spec.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[DongShengXue]

In https://wiki.mozilla.org/WebAPI/DeviceStorageAPI, The comment is
// Returns the result as a FileHandle object which enables writing
DOMRequest getEditable(DOMString name);

But I printed the result, it is File object not FileHandle object. 
var myDB = window.navigator.getDeviceStorage('music');
var req = myDB.addNamed(dummyblob, fileName);
req.onsuccess = function() {
var req2 = myDB.getEditable(fileName);
req2.onsuccess = function() {
var file = req2.result;
console.log('getFileEditable: ' + file);
//file.open("readwrite"); //can not find open method
}
}

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

Is there a time-frame for fixing this? getEditable() is required for bug 891030, which we want for 1.2.

Comment 2

[Dave Hylands [:dhylands]]

(In reply to Mike Habicher [:mikeh] from comment #1)
> Is there a time-frame for fixing this? getEditable() is required for bug
> 891030, which we want for 1.2.

No specific time frame. I think that since we have a fairly simple workaround of rewriting the entire file (not very performant, but functional), I think that the priority of this will be decreased.

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Dave Hylands [:dhylands] from comment #2)
> 
> No specific time frame. I think that since we have a fairly simple
> workaround of rewriting the entire file (not very performant, but
> functional), I think that the priority of this will be decreased.

My only concern there is the memory requirement of keeping two Blobs around.

Comment 4

[Gabriele Svelto [:gsvelto]]

I've just run into this while working on bug 914532. To avoid an OOM when exporting a large number of contacts with images I am processing them in batches and I hoped to be able to stream the data out progressively. Unfortunately it doesn't look like I'll be able to do it soon :-( Since bug 914532 is a koi+ is there another possible workaround? Writing out separate files and then gluing them all together at the end would be OK too.

Note that I'm not adding the bug as a dependency yet otherwise triage would koiplusify this bug and I don't think that we would want that.

Comment 5

[Dave Hylands [:dhylands]]

(In reply to Gabriele Svelto [:gsvelto] from comment #4)
...snip...
> Note that I'm not adding the bug as a dependency yet otherwise triage would
> koiplusify this bug and I don't think that we would want that.

No - this bug is a fairly significant chunk of work, not something simple (or it would have been done long ago)

Comment 6

[Craig Comstock]

Is there a workaround to edit files? I tried enumerateEditable and getEditable neither of which returns a FileHandle object. Is it the same problem for enumerateEditable and getEditable? Since there is no way to make a backup of a file I don't like the read, delete, rewrite option that I think is suggested.

Comment 7

[Dave Hylands [:dhylands]]

Currently the read/rewrite is the only workaround that I'm aware of.

Comment 8

[Fernando Jiménez Moreno [:ferjm]]

Dave, could you describe what's the work left to do here now that the locking functionality is implemented, please? Thanks!

Comment 9

[Dave Hylands [:dhylands]]

I'll take a look and check. Leaving ni? on myself so I don't forget.

Comment 10

[Dave Hylands [:dhylands]]

I think that this code:

https://dxr.mozilla.org/mozilla-central/source/dom/devicestorage/nsDeviceStorage.cpp?from=nsIFileToJsval#1913-1916

needs to be fixed to return a FileHandle object (sounds trivial, but I'm not sure how you even go about creating a FileHandle object, so it's probably more complex than it seems).

Comment 12

[BMO Automation]

Firefox OS is not being worked on