Drag and Drop files on Linux fails from Firefox to Firefox
Categories
(Core :: Widget: Gtk, defect, P3)
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),
- open https://gist.github.com/
- open local directory with Firefox
- Drag&Drop from local directory listing to the Gist
- 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
Updated•5 years ago
|
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 "
Comment 2•5 years ago
|
||
The priority flag is not set for this bug.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•5 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
Hello, do you still se this problem? I tried to follow the steps but I'm not sure what's:
- open local directory with Firefox
I don't think this is supported. Can you explain it?
Thanks.
Comment 4•3 years ago
|
||
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.
Assignee | ||
Comment 5•3 years ago
|
||
I see, thanks. That's something different that I expected but I can reproduce it.
Assignee | ||
Comment 6•3 years ago
|
||
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.
Assignee | ||
Comment 7•3 years ago
|
||
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.
Assignee | ||
Comment 8•3 years ago
|
||
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.
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.
Assignee | ||
Comment 10•3 years ago
|
||
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.
Assignee | ||
Comment 11•3 years ago
|
||
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?
Assignee | ||
Updated•3 years ago
|
Comment 12•3 years ago
|
||
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
Assignee | ||
Comment 13•3 years ago
|
||
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.
Assignee | ||
Comment 14•3 years ago
|
||
And I'd like to achieve a consistent user experience i.e. D&D will work intuitively for all types / destinations.
Assignee | ||
Comment 15•3 years ago
|
||
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).
Comment 16•3 years ago
|
||
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?
Assignee | ||
Comment 17•3 years ago
|
||
(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 tofile:///
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.
Comment hidden (obsolete) |
Updated•2 years ago
|
Description
•