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

Fully support setting acceptedFiles as .fileending #107

Closed
wirmar opened this issue Mar 3, 2020 · 3 comments
Closed

Fully support setting acceptedFiles as .fileending #107

wirmar opened this issue Mar 3, 2020 · 3 comments

Comments

@wirmar
Copy link

wirmar commented Mar 3, 2020

input type=file also supports setting the acceptedFiles as file endings. (e.g [".jpg", ".png"]), see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file#Unique_file_type_specifiers
This is useful for custom file types whose mime type is not known by the browser.

What already works:

  • When clicking the dropzone to open the file explorer to select a file, the files are already filtered to only show the files with the provided file endings. (Tested on windows)
  • When dropping an unsupported or supported file ending the file is accepted or rejected as expected.

What doesn't work:

  • When hovering a file over the dropzone it always shows the "wrong file type" hover state (red), even if the file is accepted when dropped.
@panz3r panz3r mentioned this issue Mar 26, 2020
@panz3r
Copy link
Contributor

panz3r commented Apr 22, 2020

Should be resolved as of PR #121 .

For more details about supported file types and filters see section Accepting specific file types of react-dropzone docs here.

@panz3r panz3r closed this as completed Apr 22, 2020
@Camsteack
Copy link

Hi,
This doesn't seem to be work on the last version 3.2.1. When I hover the dropzone I still always shows the rejected red state if I use file extensions, but reading the react-dropzone documentation it won't be working anyway no ?

Thanks a lot

@sli
Copy link

sli commented Jun 26, 2020

Yep, I can confirm that the described bug is present (still or again) in 3.3.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants