Closed Bug 859696 Opened 7 years ago Closed 2 years ago

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

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: dxue, Unassigned)

References

Details

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
}
}
Is there a time-frame for fixing this? getEditable() is required for bug 891030, which we want for 1.2.
Flags: needinfo?(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.
Flags: needinfo?(dhylands)
(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.
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.
(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)
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.
Currently the read/rewrite is the only workaround that I'm aware of.
No longer blocks: 945350
Dave, could you describe what's the work left to do here now that the locking functionality is implemented, please? Thanks!
Flags: needinfo?(dhylands)
I'll take a look and check. Leaving ni? on myself so I don't forget.
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).
Flags: needinfo?(dhylands)
Duplicate of this bug: 908417
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.