I have simple input for uploading files and it only accepts .class files:
<input type="file" accept=".class">
Problem is that accept property (accept=".class") causes dialog to open very slowly in Chrome, it sometimes takes even up to 10 seconds, but it works perfectly in Mozilla Firefox and Internet Explorer. I am using latest version of Chrome - 53.0.2785.116 m (64-bit). I find this really silly because other extensions work perfectly in Chrome as well. I have read other questions with similar problems, some of them suggested that adding name property may fix the problem, but it doesn't help in this case. Problem is really easy to reproduce, you only need the line of code I provided.
Edit:
Google published an update today - 53.0.2785.143 and it seems to have fixed the problem.
This is a known regression bug in Chrome version 52.0.2743.116.
The temporary workaround is use mime type and be explicit (no wildcards). Ex replace:
<input type="file" name="images[]" multiple="multiple" accept="image/*">
with:
<input type="file" name="images[]" multiple="multiple" accept="image/gif, image/png, image/jpeg, image/bmp, image/webp">
To solve your specific problem this should work:
<input type="file" accept="application/java-vm"> per the mime types list
Related
Here's a very weird bug that occurs in Safari 15.3 and 15.4 (macOS) but not in any other browser.
If I have the following element:
<input type="file" accept=".json,.cbor">
I can select any .cbor file.
However, if I do:
<input type="file" accept=".json,.jpg,.cbor">
Safari shows a 'tempImageXXXXX.jpg' name and does not select the actual file.
This only happens for .cbor files in our test, but I assume it might have something to do with unknown mime types? .wav, .json, .jpeg, .mp4, etc. all have no issues. Also no other browser has any issues with this. Re-ordering the extensions in the element neither.
To replicate: just rename a txt file to .cbor and paste the code above into jsfiddle.
try using this:
<input type="file" accept="application/json,image/jpg,.cbor" />
if that did not work fine, try changing .cbor with text/plain
The actual answer is that Webkit (the web engine behind Safari) is converting images when an image mime-type is listed in the accept tag of an HTML element. This has been introduced with the following change in Webkit and it is used in their example to transform HEIC images into JPEG on the fly when an image is drag and dropped from the Photos app.
However, at Ocus, we discovered a bug linked to this change. For some mime-types (which I haven't been able to list) the name of the file is changed to tempImageXXXXX. The OP's fix worked because they used image/* instead of a specific image mime-type in the accept field.
So, the real fix is the above bug.
What you can do meanwhile is use:
<input type="file" accept="application/json,image/*,.cbor" />
You can check for specific image mime-type by plugging into the input's events.
I want to filter files user can select into <input type='file'>
So I wrote :
<input class="form-control" accept="video/*" name="my_video" id="my_video" type="file"> for video
and <input class="form-control" accept="image/*" name="my_picture" id="my_picture" type="file"> for an image
I do tests with Linux browsers :
Firefox 53.0 (64 bits)
Chromium 58.0.3029.81 (64-bit)
both do not filter file types.
I looked around on stackoverflow. Syntax seems good. But even examples from that discussion does not work for me.
I checked on MDN as well. Nothing to help me.
I also tried to put directly file extension like accept="png" accept=".png", accept="*.png". With same result.
Does someone have a clue to make accept parameter work?
Code is too simple and it shows no error on Chrome.
But for cross-browser functionality you can use jquery code or Bootstrap File Input
Anybody knows why this input accepts .php file extensions?
( At least in the latest version of chrome )
<input type="file" accept=".doc,.pdf,.txt,.rtl">
This is apparently a Mac Os only bug.
I wasn't able to reproduce it from my win10 VM, but it is still there in v.55.0.2861.0 canary.
The problem seems to come from the .txt.
It's like it will accept any text/* files, when this extension is set.
You can star this chromium issue which treats of the same underlying issue (with a different extension).
<input type="file" accept=".txt">
When I use <input type="file" accept="image/*"/> with Chrome, it opens the dialog very slowly (more than 10s on Mac 10.11.6 with Chrome 52.0.2743.116 64-bit).
But when I remove accept="image/*", it becomes right. And I’ve look at my Facebook page, it works fine. What's different?
Stack Overflow's picture upload also becomes so slow with my Chrome.
What happens to my Chrome? I’ve tested other’s Chrome, it’s OK…
UPDATE in Jul. 2017: This is confirmed as a bug in Chrome, and it is fixed now.
The root cause of this bug is: Chrome's SafeBrowsing feature will check file on uploading or saving. If the internet connection to google's server is fast, it's OK. But if the connection is slow or broken, SafeBrowsing will make Chrome hang for a few seconds, until the check is finished or timeout.
Using accept="image/png, image/jpeg, image/gif" will workaround this issue because MIME types image/png, image/jpeg, image/gif are in the whitelist of SafeBrowsing -- no check is needed. However, for accept="image/*" or accept=".apk", as it's not in the whitelist, SafeBrowsing will trigger the check and hang Chrome.
This bug has been fixed by skip the check on uploading.
Note: I get the above information from a Chinese article written by Wang Lei, who is inspired by #cute_ptr's answer. Thanks to Wang Lei and I think #cute_ptr's answer deserve an upvote.
UPDATE: Thanks to #xiefei's comment, the final workaround would be:
<input type="file" name="imgFile" accept="image/png, image/jpeg, image/gif">. If necessary, other image MIME types can be appended.
This bug is reproduced on my machine: Mac + Chrome + <input type="file" accept="image/*">. It seems like a Chrome bug on Mac when accept attribute is used, as it's not reproduced on Windows environment, or on other browsers.
I Think I may have found the reason, at least on my machine:
When my internet connection is on, it opens fast the file dialog, when I turn it off, it is slow, then I turn it on again and it is fast again.
Therefore try opening the file dialog when your internet connection is on, and see if there is any difference. It worked for me.
From the best answer, we have known this is a chrome bug and ready to be fixed. Until today(2017/08/23), chrome 60.0.3112.101 has not fixed this bug yet. However latest chrome canary(62.0.3194.0) has fixed it.
I want to allow users to select a local directory on a webpage (and then read all the files in the directory).
In Chrome I can add the webkitdirectory attribute to enable this functionality. According to a comment in this question and an answer to this question you should be able to do the same in firefox using mozdirectory but I am unable to get it to work.
I have tried the following in Firefox with no luck (works in Chrome):
<input type="file" id="files" name="files[]" multiple mozdirectory="" webkitdirectory="" directory="" />
My Firefox version is 10.0.
Are there any way for a user to select a directory for input in Firefox without requiring an add-on on the client-side (like Flash)?
Firefox doesn't have any API to upload directories yet (which is a shame)...not even in the nightly builds, so I don't think we will see support on this very soon. IE doesn't have one either. If you want to take advantage of this feature you must force the users to use Google Chrome (e.g. make them aware that upload directory is available only in Chrome).
A workaround would be to compress the directory in a .zip file and read it with the FileReader API. See https://stackoverflow.com/a/7842896/613453
Update
IE Edge now has support for this.
https://msdn.microsoft.com/en-us/library/mt574730(v=vs.85).aspx
Now you can upload directory using drag and drop with chrome
read this article you will get more info
http://updates.html5rocks.com/2012/07/Drag-and-drop-a-folder-onto-Chrome-now-available