electron: DataTransfer.files not available in drag events (using file protocol)

  • Electron version: 1.7.3
  • Operating system: Linux and macOS

Expected behavior

When using the file protocol event.dataTransfer.files was available to drag events even before the drop event (at least up to Electron 1.6.11) (see related discussion #8720) – in Electron 1.7.3 the file list is always empty.

Actual behavior

Files are not available.

How to reproduce

Register dragover or dragenter and drag files over the application.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 10
  • Comments: 37 (27 by maintainers)

Most upvoted comments

Hey friends—it looks like this is still an issue in 1.7.11. Does anyone have any insight into whether or not this will be fixed in an upcoming version of Electron and/or should I start looking into work arounds? Thanks!

Using 1.8.4 and still an issue for me. DataTransfer.files are not available on onDragEnter event. Nor on onDragOver. onDrop does work.

@nornagon That seems like a cleaner way to go. Maybe the renderer could pass one of the opaque DragEvents to main via IPC, and main could pull the underlying file info, via some API on webContents? I don’t know much about Chromium/Electron’s internals so I’m not sure where to start with this, but it seems like it should be possible.

I have a fix for this working locally. It more or less reverts the diff mentioned earlier in Chromium/Blink. It sets the DataTransferAccessPolicy to the more permissive “Readable” (instead of “TypesReadable”) when the document is from a file:// or localhost URL.

I’m not sure if there’s appetite for a Blink patch? But I can try to make a PR if it’s viable. (this would also be my first Electron PR and I might need some guidance) edit - this is the patch

@astoilkov yes, it’s only a workaround. It will only work if the mime-types in question are properly registered at the OS level (I think! I’ve only used well-known types so far, it’s possible that this is registered somewhere in Chromium). Also, it does not give you a clear mapping to files; but having the types available at least mitigates the issue in some cases. I was just pointing this out, because the issue was about the be closed and I think we’ll have to decide, in principle, if this is something Electron wants to fix.

I don’t think there’s a chance that Chromium would decide to go back to the old behaviour of including the files for the file:// protocol so the only way to fix this is to backport the old behaviour and maintain it going forward. This would definitely be the best solution for Electron users, but I’m not it’s worth the effort. (For the record, I’ve had this on my TODO list for two years, but since the workaround using mime-types is good enough for our app so far, I haven’t looked into it.)

@greggman we do not really have a fix for this, our workaround was to not rely on this information anymore, but the functionality degraded because of that decision.

yes it’s still an issue

For me I just need to know the types of the files, not their paths. I still get event.dataTransferItems.types but it only handles a few types. Examples, when I drag the follow files I see the corresponding type

foo.exe    application/x-msdowload
foo.txt    text/plain
foo.json   <empty string>
foo.xlsx   <empty string>
foo.docx   <empty string>
foo.png    image/png

If I could register more extention->type settings via some API that would be enough for me although I’m all for getting the actual filenames in Electron

@bpasero is there a link to your workaround?

This is still open (you cannot access DataTransfer.files on drag in anything above Electron 1.6).