Open
Bug 1383372
Opened 8 years ago
Updated 3 years ago
Firefox ignores certain combinations of X11 Drag-and-Drop mimetypes
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)
Tracking
()
UNCONFIRMED
| Tracking | Status | |
|---|---|---|
| firefox56 | --- | fix-optional |
| firefox57 | --- | fix-optional |
| firefox58 | --- | wontfix |
| firefox59 | --- | fix-optional |
People
(Reporter: from_bugzilla3, Unassigned)
Details
Attachments
(1 file)
|
965 bytes,
text/x-python
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
Build ID: 20170627155318
Steps to reproduce:
1. Visit a site with a <input type="file"> field like iqdb.org
2. Test dragging and dropping files from PCManFM (a file manager)
3. Test dragging and dropping files from Audacious Media Player
4. Test dragging and dropping files from a Geeqie (image manager) collection window
(Tested using an up-to-date Lubuntu Linux 14.04 LTS with Geeqie downgraded to 1.0 from Lubuntu 12.04 to fix a crash bug.)
Actual results:
Dragging and dropping from PCManFM and Audacious works but nothing happens when attempting to drag-and-drop from the Geeqie collection window.
Expected results:
Firefox should accept dragging and dropping files from any of the three sources, as PCManFM does.
| Reporter | ||
Comment 1•8 years ago
|
||
Using the PyGTK dragtargets.py demo, I looked at what was being offered by the three sources. Here are the results:
PCManFM 1.2.0 (works with Firefox):
text/uri-list
application/x-fmtlist-ptr
UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
text/plain
Audacious Media Player 3.8.2 (works with Firefox):
text/uri-list
Geeqie 1.0 (doesn't work with Firefox):
text/uri-list
text/plain
At the moment, I don't have test code handy to check whether the problem might actually be that Geeqie serializes to some less common but de facto valid format for text/uri-list,
I'll try to check that when I can spare the time.
Updated•8 years ago
|
Component: Untriaged → Drag and Drop
OS: Unspecified → Linux
Product: Firefox → Core
| Reporter | ||
Comment 2•8 years ago
|
||
Ok, I hacked together some quick little test code. (A copy of dragtargets.py which dumps the content from text/uri-list or text/plain offerings, in that precedence order, to stdout.)
I was premature in titling this.
The title should be changed to some variant of "Firefox does not support improperly-constructed file URLs that all other tested Linux drag-and-drop clients do"
Geeqie produces URLs of the form "file:/home/ssokolow/Test Image.png"
Applications which work produce URLs of the form "file:///home/ssokolow/Test%20Image.png".
(Note the single slash after "file:" and the lack of percent escaping)
I tested drag-and-drop from Geeqie's collection view to PCManFM (LXDE), Thunar (Xfce), DolphinPart (used in KDE's Dolphin and Konqueror), AND CHROMIUM. The three file managers resulted in a successful file copy operation and Chromium accepted the path as valid.
That this is supported consistently suggests that there are enough applications which produce URLs for drag and drop by blindly prepending "file:" onto un-escaped filesystem paths that Firefox should support this case. (Plus, it's also an issue of reaching functional parity with Chrome.)
Updated•8 years ago
|
Updated•8 years ago
|
status-firefox58:
--- → wontfix
status-firefox59:
--- → fix-optional
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•