Fix regressions in 3.0.0

[feross]

Dropping a folder no longer works, because we preferred the code path that uses e.dataTransfer.files instead of e.dataTransfer.items, and I also removed the code for e.dataTransfer.items. Turns out that's how directory support was implemented. My bad for not noticing.

I reverted and found another way to address these issues:

#38
#34

The new API:

dragDrop('#dropTarget', function (files, pos, fileList) {
  console.log('Here are the dropped files', files) // this is an Array
  console.log('Dropped at coordinates', pos.x, pos.y)
  console.log('Here is the raw FileList object if you need it:', fileList)
})

1. We need to prefer e.dataTransfer.items since it gives us directory support. That object is an Array, so the FileList feature request is affected (Make sure we use the standard API for file drops if it's available #38). But I'll also return e.dataTransfer.items (the FileList) as the third argument. That way, if you need the FileList you can still get access to it.

2. As for the bug where the file type is sometimes empty in Chrome (Empty type for some file types in Chrome #34), that bug will return. However, if you want to, you can use the third argument to get at the FileList which doesn't have this Chrome bug.

Note: that for both the above use cases, the FileList will be useless when a directory is dropped, since e.dataTransfer.files can't show the files within the directory. But that's just a fundamental limitation we can't get around for now.

Hope this satisfies everyone.

[feross]

Released as 4.0.0.

[arturi]

Thank you! Yeah, so basically, if we want folders, we should accept that there will be no/incorrect file types sometimes (bad for client-side validation). If file types are important, we should disallow folders. transloadit/uppy#364

[feross]

@arturi Or you can do your own mime type detection based on file extensions which is what the browser is certainly doing. :)