GNOME Bugzilla – Bug 784038
drag & drop from GVFS share to chromium based apps does not work
Last modified: 2017-10-18 16:36:47 UTC
It is currently not possible to use the file and folder drag & drop functionality from Nautilus with chromium and electron based apps. Basically, they will receive a drop event that passes along the text links to the GVFS mounted files (like sftp://test.rebex.net/readme.txt), but the expected behaviour would be that a file drop event is produced that will provide the real gvfs mount path of the files that are dragged e.g /run/usr/1000/gvfs/test.rebex.net/readme.txt Copying a file from a gvfs mount in nautilus to the clipboard and running `xclip -o -selection clipboard -t x-special/gnome-copied-files` also returns the "sftp://..." link. Is nautilus actually putting the mounted path (/run/usr/1000/gvfs/...) onto the clipboard somewhere, or just the "sftp://..." link? This might actually not be an issue with nautilus itself, but any help from your side would be very appreciated. We would really like to get this issue resolved, as it currently prevents users from opening gvfs mounted files and folders via drag and drop in "Atom" or "VS Code" or any other electron based apps. The related chromium issue is filed here: https://bugs.chromium.org/p/chromium/issues/detail?id=734959# And the related electron issue is filed here: https://github.com/electron/electron/issues/9319
We use gvfs for interaction with other desktop apps, where using gvfs gives us benefits. Those electron apps should do g_file_is_native and then g_file_get_path to get an actual path, if it exists. We could do the transformation to a path from our side, but we will lose the benefits of using gvfs for a not so clear benefit of webapps that are not very well integrated in the desktop in the first place. So I'm tentatively closing this as NOTGNOME, but feel free to come up with solutions/cases so we can reconsider it.
Thanks for your help, I clearly see your point and I think it should be fixed on the chromium side.
I made some tests and think a little about it. When we convert to a path, the destination application can create a GFile and convert to an URI again. So actually it might make more sense for us to provide the path, so those other non-gio apps can handle it just fine without relying on GLib. Only thing I want to make sure is that all of our apps do the get_uri properly when dnd from Nautilus, then we can perfectly move forward on always providing a path rather than a URI. Reopening based on that.
I talked with a webkit developer and chromium maintainer in RHEL, and seems they definitely depend on GLib already, so they can fix it on their side too with not too much hassle. Good thing if they fix it on their side is that they can provide a dialog with a warning in case the path cannot be converted to native. It nautilus has to do the conversion, it will just send "null" and Chromium won't know what's going on and neither the user in case the file cannot be converted to native.
s/it/if
GVfs translates the FUSE paths internally back and was designed to be used as it is described here as far as I can tell. You should use the FUSE paths where possible because GLib-based apps handle them natively and other apps can still open them... (Just a note that some applications like Firefox can handle e.g. FTP URIs itself, so it would also make sense for few applications to use the URIs instead of the paths, but this is negligible...)
(In reply to Carlos Soriano from comment #4) > Good thing if they fix it on their side is that they can provide a dialog > with a warning in case the path cannot be converted to native. It nautilus > has to do the conversion, if will just send "null" and Chromium won't know > what's going on and neither the user in case the file cannot be converted to > native. If g_file_get_path returns NULL, then you should probably use the URI as fallback...
Sounds good, thanks Ondrej.
Thanks for putting your efforts into this, very appreciated! To summarise: 1. changing the current behaviour in nautilus seems to be a viable option because apps that do not use glib would benefit from it - but this can only happen once we are sure that none of the gnome apps break because of this change. 2. as an alternative, chromium, that already depends on glib could implement the fix by resolving the path using glib's g_file_get_path and g_file_is_native calls. Please let me know if you get stuck on 1.) so I can communicate back to the chromium team to go with option 2.)
(In reply to Thomas Zilz from comment #9) > Thanks for putting your efforts into this, very appreciated! > > To summarise: > > 1. changing the current behaviour in nautilus seems to be a viable option > because apps that do not use glib would benefit from it - but this can only > happen once we are sure that none of the gnome apps break because of this > change. As far as I can tell it was used by default for many years and should not cause any problems for GNOME apps, it has to be changed recently... Carlos, any idea why it was changed?
(In reply to Ondrej Holy from comment #7) > (In reply to Carlos Soriano from comment #4) > > Good thing if they fix it on their side is that they can provide a dialog > > with a warning in case the path cannot be converted to native. It nautilus > > has to do the conversion, if will just send "null" and Chromium won't know > > what's going on and neither the user in case the file cannot be converted to > > native. > > If g_file_get_path returns NULL, then you should probably use the URI as > fallback... I missed that bugreport a few weeks ago, but submitted a patch to Nautilus to do just that there: https://gitlab.gnome.org/GNOME/nautilus/issues/12
As per the GitLab duplicate, this is fixed by commit 03b540dbe9b59016e4392b710023aa675ffbc382. The fix will be available in the next version.