Open Bug 1599120 Opened 5 years ago Updated 2 years ago

Drag and Drop files on Linux fails from Firefox to Firefox

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
68 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

People

(Reporter: amajer, Assigned: stransky)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

On openSUSE Leap 15.1 with 68.2.0 Mozilla Firefox (from openSUSE repository),

  1. open https://gist.github.com/
  2. open local directory with Firefox
  3. Drag&Drop from local directory listing to the Gist
  4. Nothing happens

An alternative here is to open the local directory from step 2 with Google Chrome. Then drag and drop into Firefox Gist window from Google Chrome works.

Installing Dolphin file manager and drag&dropping same file also functions.

I've then used Qt example program (dropsite) to see the actual information in the Mime messages in the drag and drop

In Firefox drag message (blocked),

"text/uri-list" --- "file:///home/adamm/test.c "
"_NETSCAPE_URL" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 0A 46 69 6C 65 3A 74 "
"text/x-moz-url-data" --- "66 00 69 00 6C 00 65 00 3A 00 2F 00 2F 00 2F 00 68 00 6F 00 6D 00 65 00 2F 00 61 00 64 00 61 00 "
"text/x-moz-url-desc" --- "46 00 69 00 6C 00 65 00 3A 00 74 00 65 00 73 00 74 00 2E 00 63 00 "
"application/x-moz-custom-clipdata" --- "00 00 00 01 00 00 00 1A 74 00 65 00 78 00 74 00 2F 00 75 00 72 00 69 00 2D 00 6C 00 69 00 73 00 "
"text/_moz_htmlcontext" --- "3C 00 68 00 74 00 6D 00 6C 00 3E 00 3C 00 62 00 6F 00 64 00 79 00 20 00 64 00 69 00 72 00 3D 00 "
"text/_moz_htmlinfo" --- "30 00 2C 00 30 00 "
"text/html" --- "<a class="file" href="file:///home/adamm/test.c"><img src="moz-icon://.c?size=16" alt="File:">test.c</a>"
"text/unicode" --- "66 00 69 00 6C 00 65 00 3A 00 2F 00 2F 00 2F 00 68 00 6F 00 6D 00 65 00 2F 00 61 00 64 00 61 00 "
"text/plain;charset=utf-8" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 "
"text/plain" --- "file:///home/adamm/test.c"

From Google Chrome (which works)

"text/plain" --- "file:///home/adamm/test.c"
"chromium/x-renderer-taint" --- ""
"_NETSCAPE_URL" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 0A 74 65 73 74 2E 63 "
"text/html" --- "<a class="icon file" draggable="true" href="file:///home/adamm/test.c">test.c</a>"
"text/uri-list" --- "file:///home/adamm/test.c "

And from Dolphin,

"text/plain" --- "file:///home/adamm/test.c"
"chromium/x-renderer-taint" --- ""
"_NETSCAPE_URL" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 0A 74 65 73 74 2E 63 "
"text/html" --- "<a class="icon file" draggable="true" href="file:///home/adamm/test.c">test.c</a>"
"text/uri-list" --- "file:///home/adamm/test.c "
"text/uri-list" --- "file:///home/adamm/test.c "
"text/plain" --- "file:///home/adamm/test.c"
"application/x-kde4-urilist" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 0D 0A "

So it appears that the additional MIME data in Firefox DnD message is causing problems.

Actual results:

see above

Expected results:

see above

Has STR: --- → yes
Component: Untriaged → DOM: Drag & Drop
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64

The Dolphin message should only be

"text/uri-list" --- "file:///home/adamm/test.c "
"text/plain" --- "file:///home/adamm/test.c"
"application/x-kde4-urilist" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 0D 0A "

The priority flag is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)
Flags: needinfo?(enndeakin)
Priority: -- → P5
Blocks: linuxdad
Component: DOM: Copy & Paste and Drag & Drop → Widget: Gtk

Hello, do you still se this problem? I tried to follow the steps but I'm not sure what's:

  1. open local directory with Firefox

I don't think this is supported. Can you explain it?
Thanks.

Flags: needinfo?(amajer)

Open file:///home/ in address bar.
Drag a file from such a directory listing to a https://gist.github.com/ tab and then drop it into the text area.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(amajer)

I see, thanks. That's something different that I expected but I can reproduce it.

Assignee: nobody → stransky
Priority: P5 → P3

It's interesting that D&D of text strip works on the same page (for instance paste a text to pastebin) but paste of file type does not work in the same FF instance.

And also it must be related to the same FF instance - when I open file:///home/ in Firefox which is running under different profile, the D&D works ok.

Can you check if the https://gist.github.com/ paste works also in Chrome -> Chrome mode? I suspect the site is buggy and does not support internal paste.

I found a similar site (http://onpaste.com/) where I test image pasting but I don't need to be logged in and it's also broken in Chrome->Chrome paste and also on Windows.

Flags: needinfo?(amajer)

Hmmmm, indeed, internal Drag&Drop doesn't work in Chromium as well as Firefox. It works from Chromium to Firefox. But it does not work from Firefox to Chromium when I go to http://onpaste.com

So (source being file:/// location with some image or source file and target is above site or gist.github.com)

Firefox to Firefox == not working
Firefox to Chromium == not working
Chromium to Firefox == working
Chromium to Chromium == not working

So the only working scenario is Chromium to Firefox.

Flags: needinfo?(amajer)

The Firefox -> Firefox D&D seems to be intentionally blocked for direct file types, see:
https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API/Recommended_drag_types
Looks like unprivileged web pages can't create direct file drop.

Note that it means "the same instance". When you do D&D between two which is running under different profile the D&D works.
For external drops Firefox generates file drop silently at widget level so it works.

One solution may be to create user initiated drops (which comes from widget level) as external and go through widget code but I'm not sure if that's even possible.

Emilio, what do you think?

Flags: needinfo?(emilio)

In Firefox drag message (blocked),

"text/uri-list" --- "file:///home/adamm/test.c "
"_NETSCAPE_URL" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 0A 46 69 6C 65 3A 74 "
"text/x-moz-url-data" --- "66 00 69 00 6C 00 65 00 3A 00 2F 00 2F 00 2F 00 68 00 6F 00 6D 00 65 00 2F 00 61 00 64 00 61 00 "
"text/x-moz-url-desc" --- "46 00 69 00 6C 00 65 00 3A 00 74 00 65 00 73 00 74 00 2E 00 63 00 "
"application/x-moz-custom-clipdata" --- "00 00 00 01 00 00 00 1A 74 00 65 00 78 00 74 00 2F 00 75 00 72 00 69 00 2D 00 6C 00 69 00 73 00 "
"text/_moz_htmlcontext" --- "3C 00 68 00 74 00 6D 00 6C 00 3E 00 3C 00 62 00 6F 00 64 00 79 00 20 00 64 00 69 00 72 00 3D 00 "
"text/_moz_htmlinfo" --- "30 00 2C 00 30 00 "
"text/html" --- "<a class="file" href="file:///home/adamm/test.c"><img src="moz-icon://.c?size=16" alt="File:">test.c</a>"
"text/unicode" --- "66 00 69 00 6C 00 65 00 3A 00 2F 00 2F 00 2F 00 68 00 6F 00 6D 00 65 00 2F 00 61 00 64 00 61 00 "
"text/plain;charset=utf-8" --- "66 69 6C 65 3A 2F 2F 2F 68 6F 6D 65 2F 61 64 61 6D 6D 2F 74 65 73 74 2E 63 "
"text/plain" --- "file:///home/adamm/test.c"

Not that this data being dragged is not a file. It's just a url. It should insert the plaintext into the textarea, and this is the behaviour I am seeing.

The directory listings viewer in firefox doesn't treat them as actual files for drag and drop. Chrome doesn't appear to either but I only tested Chrome on Mac.

I'm a bit confused by what behaviour you are expecting and what behaviour is happening. I see the file uri being correctly inserted into the textarea

I'm talking about file / image D&D. Text is handled correctly.

When you run two Firefox instances under different profiles (so there are two different applications) the D&D works as expected (i.e. file links are resolved and dropped as files).

When you do D&D in scope of one FF instance the file links are not resolved and the drop fails / is ignored. I think this is because Linux widget code resolves the file links and add extra D&D types for actual files on OS level. This isn't perfect and does not work for all links (see Bug 377621).

But there's no doubt that internal and external D&D behaves differently for the same source/destinations.
I'm using file:///home/ as source and http://onpaste.com/ as destination.

Note that https://pasteasfile.org/ can drop even internal D&D from file:///home/ - I expect the site does an extra step to accept/resolve the links.

And I'd like to achieve a consistent user experience i.e. D&D will work intuitively for all types / destinations.

Also this is not Linux specific - I can reproduce the same image D&D scenario on Windows (although I didn't tested the two profiles scenario there).

I'm confused. If I open file:///home in Firefox, when I drag I'm not performing a real file drag, I'm just dragging a link.

So I guess the fix for this would be special-casing links from documents that are created by netwerk/streamconv/converters/nsIndexedToHTML.cpp and point to file:/// URIs to add the native file content-type, right? Or what else am I missing?

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #16)

I'm confused. If I open file:///home in Firefox, when I drag I'm not performing a real file drag, I'm just dragging a link.

So I guess the fix for this would be special-casing links from documents that are created by netwerk/streamconv/converters/nsIndexedToHTML.cpp and point to file:/// URIs to add the native file content-type, right? Or what else am I missing?

Yes, you're right, thanks for the hint. When we do D&D to an external application via. widget code, we add some extra MIME types like _NETSCAPE_URL which is a URL link too.

Severity: normal normal → S3 S3
You need to log in before you can comment on or make changes to this bug.