Q: Are multiple instances of Fine Uploader on a single page supported?
A: Absolutely! In fact, our internal development page has 4 different instances of Fine Uploader running at all times. The demo page is another example where multiple instances of the library are running side-by-side.
Q: Why can't I select multiple files at once in Android?
A: Android doesn't officially support the multiple attribute on file input elements. I believe some builds of Android unofficially supported this, but I can't recall which specific versions. See case #840 for more details.
Q: I'm using core mode, but I don't want to write my own code to handle dropped files and folders. Can I use the DnD module used by UI mode?
A: Certainly, and it's quite easy to do so! Head on over to the DnD Module Documentation for more information.
Q: In IE, when my server returns its response to an upload request, I see a "Save As..." dialog box on the client. What am I doing wrong?
A: Your server's response content-type MUST be "text/plain". IE does not handle the "application/json" mime-type. You have probably read advice from others that claim "text/html" is also safe. This is not always true. You will run into problems with a content-type of "text/html" if your JSON response contains HTML.
Q: I like UI mode, but I don't want to allow my users to utilize the drag & drop feature. How can I do this?
A: Simply remove the drop zone elements from the template.
Q: Using the jQuery plug-in in core mode, I can't seem to get my upload button to appear.
A: It is important to understand that the target of your plug-in should be an existing container element for your upload
component, not the button element. Your button element must be specified separately via the
Q: Why can't I use a progress bar, drag and drop, multiple file selection, chunking, or auto-resume in some browsers?
A: Some browsers (IE9 and older, along with Android 2.3.x and older) do not support the File API the
multiple attribute on file input elements.
These are all required to give you the best possible experience.
Q: Why isn't Safari for Windows supported?
A: There is really no reason to use Safari for Windows. Webkit is better represented on that platform in Chrome. Apple doesn't appear to be interested in maintaining Safari for Windows anymore either. Switch to Chrome.
Q: Why isn't folder drag & drop uploading supported in any browser other than Chrome 21+ & Opera 15+?
A: Chrome 21 was the first browser version to implement the HTML5 Filesystem API. This is required to handle dropped folders. Currently, no other browsers support this API. Opera 15+ is based on Chromium as well, giving it feature parity with Chrome.
Q: I have created a
<button> element for my uploader button, but this doesn't seem to work in IE. Why?
A: In IE, the button element receives the click event, instead of the child input element. Use a
<div> or a
<span> or an
<a> instead. Be sure to add a
role attribute with a value of "button" to this element for accessibility reasons.
Q: Why do I only see a "Processing..." message next to a file (in UI mode for the traditional uploader) in Chrome, Safari, & Opera after the last byte has been sent but the server has yet to respond?
A: The implementation of the onProgress notification that tells us the status of the bytes sent to the server varies from browser to browser, unfortunately. Webkit browsers have elected to follow the "spirit" of the W3C spec, while Firefox, and (I believe) IE10, obey the spec in the most strict sense. I have discussed this in some detail in the "processing" status message feature case.
Q: When chunking and multipart encoded are both enabled, why must I determine the original file's name by parsing the qqfilename parameter?
A: The file data is stored in one of the multipart boundaries contained in the request payload. Normally, the content-disposition header for this boundary contains the actual file name. However, when the file is split up into parts client-side, we are sending a Blob to represent a different part of the File in each request. A FormData object is used to construct these requests. When a Blob is added to a Fo.htmlata object, the user agent sets the content-disposition header for the associated multipart boundary in the request to "blob" (or sometimes an empty or random string). As a result, we must pass the original file name in a parameter.
Q: How can I prevent users from dropping folders into browsers that do not support folder uploading?
A: There is no reliable way to prevent users from dropping folders into the drop zone of any browser other than Chrome 21+ & Opera 15+, currently. This is due to the fact that there is no way to reliably detect if a folder has been dropped unless the user agent implements the Filesystem API. Folder dropping is only supported in Chrome 21+ & Opera 15+, since these are the only browsers that implement the Filesystem API. You can parse the user agent string to determine if folder dropping is supported, and then inform your users in your application's UI. Theoretically, you could check for the appropriate function on the DataTransfer object prototype, but this would not work cross-browser, since webkit does not expose this interface, unfortunately.
Q: Why are
<input type="file"> elements I pass into the
addFiles method removed from the DOM in IE9 and older?
A: Internally, Fine Uploader must move these input elements to a
<form> that targets a hidden
<iframe>. This form is then
submitted to simulate a non-page-reloading upload. The act of moving the input to the form removes it from its original
position in the DOM. This is unavoidable as it is not possible to clone a file input element. You should clone
or re-create the
<input type="file"> after submitting it via addFiles, or simply attach the input element to
Fine Uploader via the button or extraButtons options.