You can try out this demo in a Firefox nightly build: https://bug503598.bugzilla.mozilla.org/attachment.cgi?id=388413

You can even drop multiple files at once.

XHR file upload and progress callbacks will be very useful. Progress callbacks should be available for any XHR request, not only for files.

A way to query progress even for non-XHR file uploads would also be useful but it could be skipped if the browser reports about the progress of the uploads of every single file.

@Deadmeat: access to local files is a matter of trust. The OS itself or any famous application running on your machine (Office, Photoshop, any web browser) could be sending a copy of all your files to a remote server right now. All you can do is trust your vendor or the users’ community, read the source code if available, monitor your Internet connection. The companies running web applications are usually way more obscure than the vendors of OS or mainstream applications so trust is lower. Flash and also Java (Silverlight as well?) can access files, webcam and microphone but only after prompting the user for permission and I’m sure you grant permission only to applications you trust. There are no reasons why JavaScript shouldn’t be able to do the same. The only problem I see is that it will lower the barrier to entry for attackers: there are probably less people that can write Flash, Java and Silverlight than there are that can write JavaScript. As a countermeasure permissions should be granted on a single file basis and/or variables and DOM elements getting content from local files should be marked as tainted and the browser should not be able to send their values to a remote server.

Usage of error codes in 2009 seems kind of… obsolete. Structured exceptions came from ML, where they are represented simply as datatypes. Why isn’t it the case in the IDL?

Which isn’t quite the same thing. But then writing to local files is a whole other kettle of fish opening up way too many avenues for malicious sites to write files to disk.

Quite rightly runtimes like Adobe Air et al, are much more suited for that sort of application.

This would provide a low rent way to have multipart structured files. Of course the would make the API more complex since you’d want to be able to read each part individually. This would be useful for apps that want to load and save multipart data in a single file such that you didn’t need to prompt the user to select multiple files or embed and decode multiple files in a single file.

This is easily fakeable if the file is already an MHTML document, by reading as text and parsing. I’d be nice if this was baked in though.

Would make for a really simple shorthand for generating email attachments too.

That said, I don’t agree with progress events, simply allowing the script to periodically poll the request would be simpler, and effectively the same thing.

Upload progress is something that should already be exposed in the browser. Primarily as a progress widget similar to the loading progress bars (which are largely fake, since total page size includes all the images, scripts etc.) The browser should know how big the request is, and how much data has been sent. It just needs to expose that information, visually or via JS.

This shouldn’t be limited to the request either. Responses should be accessible too. Access to data loaded, and the http size header would be nice as well, and not just for AJAX Requests. Frame, img, video, audio etc objects would be nice too. Potentially allowing for pretty pre-loaders for these elements.

However as I said, whole other kettle of fish.

I would also vote that if there is a progress API that you can specify the call rate and the callback something like this:

var rate = 2000; // milliseconds between each report
loader.registerProgressListener(rate, function(uploadedBytes,totalBytes,bytesPerSecond){
//...
})

it is important to be able to control the rate of reporting.

Access to binary data would also be a big win.

>>var file = document.getElementById("some-file-input");
>>[property for (property in file.files.item(0))].join(", ")
getAsDataURL, fileName, fileSize, getAsText, getAsBinary

start() stop() and cancel(), so it is not necessary to submit a form rather than to access it by script. DOM Events like stated above to receive information about the current upload.

Just imagine if you are just interessted in the head of a file, you can do sth like:

var input = document.getElementById(“…”);
var file = input.files.item(0);
input|file.addEventListener(“track?”, function(e) {
if (e.currentSize >= [size in kb thats needed]) {
file.stop();
// continue with e.filedata
}
}

I didn’t have a look into the spec, so the code is just to describe my words above… kinda :)