Drop Mails from Outlook does no longer work with Chromium 108

[elioschmutz]

Initial checklist

• I understand this is a bug report and questions should be posted in the Community Forum
• I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

• https://www.dropzone.dev/
• https://developer.mozilla.org/en-US/docs/Web/API/DataTransferItem/webkitGetAsEntry#result

Steps to reproduce

1. Use Windows with Outlook (.ost file saved under default path: C:\Users<userid>\AppData\Local\Microsoft\Outlook) and a browser using Chromium >=108 (newest stable release) (Edge, Chrome)
2. Drag&Drop an E-Mail to the dropzone of https://uppy.io/examples/dragdrop/

Expected behavior

The file should be uploaded as every other file. It worked as expected until Chromium 107

Other D&D plugins like the plugin dropzone.dev still work as expected. It also works when using the default D&D Guide from Mozilla: https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API/File_drag_and_drop

working-example.mov

Actual behavior

the following error message will be promted:

[Murderlon]

Hi, thanks for reporting. I don't have Windows or Outlook so I can't test this. Would you be willing to create a PR for it?

Potentially related code: #1978

[elioschmutz]

It's not directly related with Outlook, but Outlook is the main app where we see the issue in production.

Basically, chromium 108 blocks several paths and its children: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/base/base_paths_win.h#42 when using the api uppy is using.

Outlook stores its data-file under one of those paths by default in windows: DIR_LOCAL_APP_DATA

To test it with Windows without outlook:
create a file under C:\Users<userid>\AppData\Local\ and try to upload it with https://uppy.io/examples/dragdrop/

To test it with MacOS:
create a file under ~/Library and try to upload it with https://uppy.io/examples/dragdrop/

[elioschmutz]

@uppy/utils@4.1.1 introduced the issue with the following PR: https://github.com/transloadit/uppy/pull/3534/files

[Murderlon]

There were two fixes after that PR though: #3998 and #4043. Surprised those haven't caught it.

Would you be willing to investigate this further?

[elioschmutz]

I think the issue here is using the experimental getAsFileSystemHandle (https://developer.mozilla.org/en-US/docs/Web/API/DataTransferItem/getAsFileSystemHandle) method: https://github.com/transloadit/uppy/pull/3534/files#diff-d70c5ca272afda708d9b9b88673f092dc56dd1ee748f84d1b09076968570edf0R46

Experimental APIs should not be used in production. Chromium v108 changed the behavior of this function by restricting file system access for specific locations.

[Murderlon]

The fact that it's experimental shouldn't matter. If the API doesn't exist, we fallback to the old one. If the API exists but there is no response, we still fallback to the old one.

[arturi]

Hi @elioschmutz, could you please confirm if the recent release Uppy 3.4 https://github.com/transloadit/uppy/releases/tag/uppy%403.4.0 has fixed the issue for you?

[elioschmutz]

Hi @arturi thanks a lot for the fix 🎉

Is it possible to apply the patch for uppy/utils@4.1.x as well? I can't update to uppy@3.x yet.