Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docx files filtered out (but still allowed) accepting "application/*" #214

Closed
FilipeCosta06 opened this issue Jul 17, 2020 · 1 comment · Fixed by #226
Closed

Docx files filtered out (but still allowed) accepting "application/*" #214

FilipeCosta06 opened this issue Jul 17, 2020 · 1 comment · Fixed by #226
Assignees
Labels
Milestone

Comments

@FilipeCosta06
Copy link

Bug Report

Describe the bug

There is also a question/feature request at the end (if I don't forget)
.docx file hidden in input even though I am setting acceptedFiles={["application/*", "audio/*", "image/*", "text/*", "multipart/*", "video/*"]}.

According to MDN's common MIME types page, a Word document .docx file has application/vnd.openxmlformats-officedocument.wordprocessingml.document as MIME type
image

Steps to reproduce

  1. Create a DropzoneArea
  2. Set acceptedFiles={["application/*", "audio/*", "image/*", "text/*", "multipart/*", "video/*"]}
  3. Click the input and try to add a .docx file
  4. Such files won't show up and you will have to manually set the input's filter to "*" to display any .docx in the current folder

Expected behavior

Since a .docx file has a MIME type matching application/*, I expected it to be visible while opening the input.

Please note that adding a .docx file is allowed, it's just that the input's initial "filter" will hide it.
Below you can find the generated input:

<input accept="application/*,audio/*,image/*,text/*,multipart/*,video/*" multiple="" type="file" autocomplete="off" tabindex="-1" style="display: none;">

This is looking like a Chrome or OS issue and, as such, I am simply gonna allow all types using acceptedFiles={[]}.

Also, here's my "request" (booyah, didn't forget):
Please update the doc to explicitly state that acceptedFiles={[]} is the way to accept all types (turns into <input accept multiple />). Or even make it the default value :D

I just spent more time than I'd like to admit find this solution ahah. I got the hint from reading the react-dropzone's doc (by providing implies it's optional and doesn't necessarily have a default value) while this repo's doc including a default value jebaited me hard ^^ I initially tried setting "*" as a value but that would display the files in the input but not accept the selected (snack/toast error saying the type wasn't allowed), but this was expected since it didn't not respect the rules defined below.

By providing accept prop you can make the dropzone accept specific file types and reject the others.

The value must be a comma-separated list of unique content type specifiers:

A file extension starting with the STOP character (U+002E). (e.g. .jpg, .png, .doc).
A valid MIME type with no extensions.
audio/* representing sound files.
video/* representing video files.
image/* representing image files.

Versions

  • OS: Windows 10 x64
  • Browser: chrome
  • @material-ui/core version: "^4.9.13"
  • material-ui-dropzone version: "^3.3.0"

Request aside, as I mentioned, this may not be an issue related to this library. I'm posting it here just in case I'm wrong (could be my OS is mismatching MIME types and file extensions ? meh)

@panz3r
Copy link
Contributor

panz3r commented Jul 19, 2020

Hi @FilipeCosta06 ,

Thanks for your detailed feedback, as it is this is a long standing question and partly depends on the module used under the hood by material-ui-dropzone (which is react-dropzone btw) and a related issue about MIME types (issue #276).

Please update the doc to explicitly state that acceptedFiles={[]} is the way to accept all types (turns into ). Or even make it the default value :D

I can agree with you on this, changing the default would make sense to allow dropping all types of file.

@panz3r panz3r added the bug label Jul 19, 2020
@panz3r panz3r added this to the 3.4 milestone Jul 29, 2020
@panz3r panz3r self-assigned this Jul 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants