Last Comment Bug 557540 - Implement File API: Writer (FileWriter)
: Implement File API: Writer (FileWriter)
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
-- normal with 14 votes (vote)
: ---
Assigned To: Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)
: Andrew Overholt [:overholt]
: 641408 (view as bug list)
Depends on: 648997 648998 674047
  Show dependency treegraph
Reported: 2010-04-06 09:35 PDT by Jeff Schiller
Modified: 2016-09-21 11:57 PDT (History)
35 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Jeff Schiller 2010-04-06 09:35:22 PDT
The W3C has reached Working Draft with the File API: Writer spec

Firefox needs an implementation of this to match up with its FileReader implementation in 3.6 and to compete with WebKit.
Comment 1 User image Olli Pettay [:smaug] 2010-04-06 09:57:09 PDT
The draft needs to be reviewed carefully before implementing it.

But sure, this is something to do, perhaps as a GSoC project.
Comment 2 User image Jeff Schiller 2010-04-06 10:03:30 PDT
Obviously I'm implying careful review and feedback by Mozilla before implementing it... ! :)
Comment 3 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-04-06 13:48:27 PDT
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.
Comment 4 User image Jeff Schiller 2010-04-06 13:59:45 PDT
I'm just a web developer who wants this feature in my web app.  Please raise concerns/questions here:
Comment 5 User image Simon 2011-02-10 04:13:53 PST
Related to this issue probably is the implementation of the File System API [] Hopefully, this will find its way into FF soon!
Comment 6 User image Olli Pettay [:smaug] 2011-02-10 04:47:45 PST
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.
Comment 7 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-03-13 18:17:33 PDT
*** Bug 641408 has been marked as a duplicate of this bug. ***
Comment 8 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-04-11 08:00:28 PDT
Per discussions at the all hands meeting, I will be owning this.
Comment 9 User image vb4guy 2011-08-06 22:16:53 PDT
Any updates on the status of this?
Comment 10 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-16 07:15:48 PDT
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 User image vb4guy 2011-08-16 17:49:00 PDT

Thanks for the status update.  I am interested to hear what you guys come up with.
Comment 12 User image Ben Francis [:benfrancis] 2011-11-18 03:40:14 PST
I'm working on apps for the front end of 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 (

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" (, 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?
Comment 13 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-11-18 12:52:48 PST
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.
Comment 14 User image Marco Castelluccio [:marco] 2012-01-02 04:00:53 PST
FileSystemAPI limits "the scope of access to the local filesystem to a chroot-like, origin-specific sandbox".
Comment 15 User image Ben Francis [:benfrancis] 2012-01-05 02:48:50 PST
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.
Comment 16 User image Marco Castelluccio [:marco] 2012-01-05 03:23:28 PST
(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?
Comment 17 User image Ben Francis [:benfrancis] 2012-01-05 03:48:46 PST
Fair enough :)

Do you mean "File API: Directories and System"? There's a bug for that but so far the concensus is pretty negative.
Comment 18 User image Geoff Flarity 2012-04-20 06:41:18 PDT
File Writer WD was updated recently:

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.
Comment 19 User image Jonathan Watt [:jwatt] 2013-07-16 11:36:27 PDT
Should this be wontfix'ed? The "Low-level file manipulation" section at:

say's (and explains why) we're going to implement a FileHandle API instead:
Comment 20 User image Jan Varga [:janv] 2013-07-16 11:52:09 PDT
yeah, we are not going to implement FileWriter
Comment 21 User image Mounir Lamouri (:mounir) 2013-07-18 14:59:57 PDT
Lets be clear about it then.

Note You need to log in before you can comment on or make changes to this bug.