The default bug view has changed. See this FAQ.

Implement File API: Writer (FileWriter)

RESOLVED WONTFIX

Status

()

Core
DOM
RESOLVED WONTFIX
7 years ago
6 months ago

People

(Reporter: Jeff Schiller, Assigned: khuey)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
The W3C has reached Working Draft with the File API: Writer spec

http://www.w3.org/TR/file-writer-api/

Firefox needs an implementation of this to match up with its FileReader implementation in 3.6 and to compete with WebKit.

Comment 1

7 years ago
The draft needs to be reviewed carefully before implementing it.

But sure, this is something to do, perhaps as a GSoC project.
(Reporter)

Comment 2

7 years ago
Obviously I'm implying careful review and feedback by Mozilla before implementing it... ! :)
OS: Mac OS X → All
Hardware: x86 → All
Version: Other Branch → Trunk
In particular I'm not a fan of the fact that the FileWriter seems to assume that the user always grants access to indefinitely write to the file. I.e. the file contents can be changed at whim by the web page.
(Reporter)

Comment 4

7 years ago
I'm just a web developer who wants this feature in my web app.  Please raise concerns/questions here: http://lists.w3.org/Archives/Public/public-device-apis/

Comment 5

6 years ago
Related to this issue probably is the implementation of the File System API [http://www.w3.org/TR/file-system-api/] Hopefully, this will find its way into FF soon!

Comment 6

6 years ago
The file system API is a separate thing, and that needs even more careful
review if we decide to implement it.
And I'm going to propose some changes to that API anyway.
Duplicate of this bug: 641408
Per discussions at the all hands meeting, I will be owning this.
Assignee: nobody → khuey
Depends on: 648997
Depends on: 648998
Depends on: 674047

Comment 9

6 years ago
Any updates on the status of this?
We've implemented BlobBuilder (as MozBlobBuilder) which is in Gecko 6.  FileSaver will probably be in Gecko 9.  Not sure yet if/when we're going to implement FileWriter, we've been thinking of a different approach.

Comment 11

6 years ago
Kyle,

Thanks for the status update.  I am interested to hear what you guys come up with.
Keywords: dev-doc-needed
I'm working on apps for the front end of B2G (https://wiki.mozilla.org/B2G), including a camera and gallery app. Currently the only method available to store photos offline for apps like these is to base64 encode them in IndexedDB, although support for storing files in IndexedDB is coming (https://bugzilla.mozilla.org/show_bug.cgi?id=661877)

I have come across the use case that a user may take a photo using a web app on their B2G phone, then want to transfer those files to another device (e.g. a desktop PC). The most common way to achieve this is to mount the phone's storage as a USB mass storage device and copy and paste the files using a file manager.

If the "File API: Writer" spec was implemented, would the files be stored in the actual file system of the device, or in a virtual file system backed by SQLite or something else? I'm interested to know whether files written to a device via this API could be accessible as a mounted file system on a USB host.

What I'm describing may come more under another W3C specification, "File API: Directories and System" (http://dev.w3.org/2009/dap/file-system/file-dir-sys.html), which lists a use case for an "Audio/Photo editor" where "Edited files should be accessable by client-side applications [iTunes, Picasa]."?

What's the current position on the implementation of these two APIs?
Let's file a separate file for accessing USB. I agree that we need some way to do that, but FileWriter wouldn't be enough, we'd need FileSystemAPI as well which is beyond the scope of this bug.
FileSystemAPI limits "the scope of access to the local filesystem to a chroot-like, origin-specific sandbox".
True, but it also says those sandboxes are "sections of a user's local filesystem" which means that they could be accessible via USB if that file system was mounted as a USB mass storage device.

Because of the same-origin restriction that API wouldn't solve the problem of sharing files between apps (maybe Web Intents can take care of that), but it could solve the problem of getting media on and off the device.
(In reply to Ben Francis from comment #15)
> True, but it also says those sandboxes are "sections of a user's local
> filesystem" which means that they could be accessible via USB if that file
> system was mounted as a USB mass storage device.

Yes, this is what I said :D
I think we need something like the FileSystemAPI for B2G, but there isn't any open bug to implement it.
Do we want this API? Should I open a bug about it?
Fair enough :)

Do you mean "File API: Directories and System"? There's a bug for that https://bugzilla.mozilla.org/show_bug.cgi?id=704128 but so far the concensus is pretty negative.

Comment 18

5 years ago
File Writer WD was updated recently:

http://www.w3.org/TR/file-writer-api/

I'm a web developer doing some pretty innovative stuff with it and I'd hate to have to resort to using Java went users are not using Chrome.  Please, this should be implemented.

Updated

4 years ago
Summary: Implement File API: Writer → Implement File API: Writer (FileWriter)
Should this be wontfix'ed? The "Low-level file manipulation" section at:

https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/

say's (and explains why) we're going to implement a FileHandle API instead:

https://wiki.mozilla.org/WebAPI/FileHandleAPI

Comment 20

4 years ago
yeah, we are not going to implement FileWriter
Lets be clear about it then.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Keywords: dev-doc-needed
See Also: → bug 1302919
You need to log in before you can comment on or make changes to this bug.