New issue
Advanced search Search tips

Issue 734959 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Oct 26
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

[Linux] Dragging files from a GVFS / KIO share onto chromium does not reflect the correct path

Reported by thomas.z...@googlemail.com, Jun 20 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce the problem:
Open Nautilus (tested on Gnome3).
Connect to a remote server through the location bar (e.g. sftp://demo:password@test.rebex.net).
Drag a text file from the remote server onto chromium.

What is the expected behavior?
Chromium should open the file from the mounted path (e.g. /run/usr/1000/gvfs/<gvfs-share-name>/path/to/file)

What went wrong?
Chromium tries to open the underlying link (e.g. sftp://user@my-server:22/path/to/file) and not the file (e.g. /run/usr/1000/gvfs/<gvfs-share-name>/path/to/file)

Coming from electron and listening for the document "drop" event, I was able to isolate the problem as follows:

```javascript

document.addEventListener('drop', (evt) => {

   // will log 0
   console.log(evt.dataTransfer.files.length);

   // will log the url to the file
   // e.g. sftp://user@my-server:22/path/to/file
   for (let item of evt.dataTransfer.items) item.getAsString((uri) => console.log(uri));

})

```

As it turns out, dragging a file from the remote share is seen by chromium like dragging a text link, rather than a file.

Did this work before? No 

Does this work in other browsers? No
 Firefox does nothing.
Chrome tries to open the underlying remote link (e.g. sftp://server/path/to/file).

Chrome version: 58.0.3029.110  Channel: stable
OS Version: OS X 10.12.5
Flash Version: 

I have originally opened this bug with the electron issue tracker, see:
https://github.com/electron/electron/issues/9319

This bug prevents Linux users to drag files and folders from remote shares into Electron based apps like "Atom", which basically kills the feature of editing files remotely.
 

Comment 1 by jsb...@chromium.org, Jun 20 2017

If I copy a file from a mounted server and inspect the clipboard with:

xclip -o -selection clipboard -t x-special/gnome-copied-files

... or drag a file onto a terminal window, I get:

sftp://test.rebex.net/readme.txt

Is Nautilus actually putting the mounted path ("/run/usr/...") onto the clipboard or just the "sftp://..." link? Do you have a way of determining that? 


Comment 2 by jsb...@chromium.org, Jun 21 2017

Status: Untriaged (was: Unconfirmed)
To confirm: I can repro the issue

1. Desktop Menu > type 'Nautilus' and 'Files' app will show
2. Gear menu > Connect to server
3. sftp://test.rebex.net
4. Skip any automated key popups that appear
5. When prompted for username/password use username: demo password: password

But... I'm not sure what the expectation is for apps here since it does not appear a usable file path is being put on the clipboard.
I have just filed an issue with the gnome bug tracker over here:
https://bugzilla.gnome.org/show_bug.cgi?id=784038

I got an answer from the gnome bug tracker:

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.

Comment 5 by jsb...@chromium.org, Jun 22 2017

Labels: -Pri-2 -OS-Mac OS-Linux Pri-3
Status: Available (was: Untriaged)
Seems like we could then have Gnome-specific code that translates text/uri-list entries from gvfs strings to paths.

Grepping about, there is gnome-specific support for keyring integration. So not unheard of.

Not high priority, so external contributions here would be welcome.
This issue has just been solved for Nautilus via https://gitlab.gnome.org/GNOME/nautilus/commit/03b540dbe9b59016e4392b710023aa675ffbc382

Please feel free to close this issue.
Project Member

Comment 7 by sheriffbot@chromium.org, Oct 19

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Fixed (was: Untriaged)
Thank you for the update, thomas.zilz. Closing as per #6 :)

Sign in to add a comment