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.
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.
Component: Untriaged → Drag and Drop
OS: Unspecified → Linux
Product: Firefox → Core
Created attachment 8889028 [details] Quick-and-dirty test PyGTK-based test code 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.)
status-firefox56: --- → fix-optional
status-firefox57: --- → fix-optional
Priority: -- → P5
status-firefox58: --- → wontfix
status-firefox59: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.