Non-enumerable type field on file when dropping parent folder containing .docx file

[mishawakerman]

react-dropzone version: v0.1.8
browser: Chrome Version 72.0.3626.119

The change from v0.1.7 → v0.1.8 (and still broken in v0.1.9) appears to have broken the file type field returned on nested files when dropping a folder containing .docx files (it does not appear to effect all file types such as .pdf files).

In v0.1.8, when we drop a .docx file directly onto a Dropzone the file has the correct type field and everything works as expected. When we drop a folder containing the same file, the type field is 'non-enumarble/'greyed out' screenshot.

In our specific case, this prevents the file type from being set when we upload the file object with axios which results in validation errors.

[mishawakerman]

Temporary workaround

before:

onDrop={this.handleAddFiles}

after:

onDrop={(newFiles) => {
    const modifiedFiles = newFiles.map(f => {
        // clone file and re-add path
        const modifiedFile = new File([f], f.name, { type: f.type });
        modifiedFile.path = f.path;
        return modifiedFile;
    });
    this.handleAddFiles(modifiedFiles);
}}

[rolandjitsu]

@mishawakerman please try v0.1.10 and let me know if the issue persists.

[mishawakerman]

Thanks @rolandjitsu, amazing response time. Will take a look and report back

_{Sent with GitHawk}

[mishawakerman]

This fixed the issue of the type being non-enumerable. But we're still having issues (that manifest as the mimetype being stripped when uploaded) with the file objects being returned when we have a .docx in a nested folder (no issues if they are dropped directly and no issues with PDFs). Our workaround above with creating a new File appears to still work to fix our problem. I'll create a new issue.

[rolandjitsu]

@mishawakerman please provide a proper example illustrating your issue. But from your screenshot, I see the correct type application/vnd.openxmlformats-officedocument.wordprocessingml.document. So I'm not following what your issue is 😕