Devextreme: dxFileUploader: Problem with extension based values of accept attribute when using drag&drop

[drugarce]

Steps to Reproduce:

1. Create an instance of dxFileUploader with the accept attribute as ".jpg", an arbitrary upload url, and uploadMode to instant
2. Using _Drag and Drop_, drop a file called "PROFILE.JPG" onto the widget
3. Using _Drag and Drop_, drop a file called "profile.jpg.bak" onto the widget

Results You Received:

Step 2 - Nothing happens
Step 3 - Upload begins

Results You Expected:

Step 2 - File should have started uploading
Step 3 - File is rejected, upload does not start

Environment Details:

DevExtreme 17.1
Latest Chrome on Windows 10

[DokaRus]

Hi,

The accept option value is passed to the accept attribute of the underlying input element. This attribute provides hints for the browser and doesn't validate the selected file type. E.g., refer to the elements with type='file'[link] article from MDN:

The accept attribute doesn't validate the types of the selected files; it simply provides hints for browsers to guide users towards selecting the correct file types. It is still possible (in most cases) for users to toggle an option in the file chooser that makes it possible to override this and select any file they wish, and then choose incorrect file types.
Because of this, you should make sure that the accept attribute is backed up by appropriate server-side validation.

You can validate the selected value in the valueChanged event handler as demonstrated in the code snippet below:

```
dxFileUploader({
onValueChanged: function(e) {
var files = e.value;
if(!isAllowedFiles(files)) { //check the file type here
e.component.option("value", e.previousValue); //if the file is unacceptable - return the previous value
}
}
})

[drugarce]

Hi @DokaRus ,

Thank you so much for looking into this. Perhaps you missed out on the bit that the scenario I described happens when using drag and drop to add a file to the upload control. Otherwise the widget works as expected when opening the native browser file selector.

Your suggestion to use the onValueChanged handler would work for Step 3 but not Step 2 in my original posting. For Step 2, the value array of the object (e) that the handler function receives is empty. The widget discards the file as not allowed before calling the value changed function.

Please check the _dropHandler function, you will see that on line 934 there is some filtering applied on the values (files) that are provided by the html input element. This filtering is not done properly, the problematic area is on lines 978-983 in the same file.

So once again, let's say the accept attribute is *.jpg

Based on the _isFileTypeAllowed function, (978-983), a file with name "profile.JPG" will be treated as not allowed because the case of the extension does not match!
By the way, when using the native file selection dialog, the file with upper cased extension can be selected without problems, but if I drop the file on the widget, the file is ignored.

Furthermore, a file with name "profile.jpg.old" will be treated as allowed, because the ".jpg" portion is contained in file name. However, based on the accept attribute, the extension needs to be at the end of the file name, not anywhere in the file name.

[DokaRus]

@drugarce Thanks for the clarification. I've reproduced this behavior on my side and created a corresponding ticket in our SC.

[komarovalexander]

Fixed in PR