Inconsistent mimetype in webui file drag and drop

When using drag and drop, the mime-type is not the same when uploading with or without metadata

• without metadata: the mime-type is detected server side (POST nuxeo/api/v1/upload/BATCH_ID/execute/FileManager.Import
• with metadata: the mime-type comes from the client OS (batch uploader + POST nuxeo/api/v1/path/DOCUMENT_PATH)

How to reproduce drag & drop without metadata:

• log in the Web UI
• within a given folder, drag a file (e.g. a PSD file) from local machine and drop it into that folder in the Web UI
• In the IMPORT tab, directly click on the Create button

How to reproduce drag & drop with metadata:

• log in the Web UI
• within a given folder, drag a file (e.g. a PSD file) from local machine and drop it into that folder in the Web UI
• In the IMPORT tab, click on the Add Properties button and select the Asset Type as Picture
• click on the Create button

When importing without metadata, the file manager is used to import the file, which uses the mimetype registry service to normalize the MIME type.

On the other hand, when importing with metadata, the REST API document resource endpoint is used. The MIME type provided by the borowser in the batch upload to the batch uploader is directly stored without normalization by the mimetype registry service.

From a user perspective, there shouldn't be two different outcomes depending on whether metadata are added during upload or not.

Relying on the server is the most robust and scalable solution.

Example: on windows, using drag and drop with a .psb file (photoshop large file formats)

• adding metadata during upload, the mime-type sent to the server is application/octet-stream. Preview generation fails because this mime-type is not supported by the jpeg converter in the configuration
• not adding metadata, the mime-type is correctly set to application/photoshop by the server (mime-type registry service)

A workaround on windows is to edit the registry to set the correct mime-type for a file extension but this is not a realistic solution for a large number of users.

Possibly the best way to fix this is to call the mimetype registry service in listener mimetypeIconUpdater at every blob upload, instead of calling it only when the MIME type is application/octet-stream here.