Open Bug 1383372 Opened 3 years ago Updated 3 years ago

Firefox ignores certain combinations of X11 Drag-and-Drop mimetypes

Categories

(Core :: DOM: Drag & Drop, defect, P5)

52 Branch
Unspecified
Linux
defect

Tracking

()

UNCONFIRMED
Tracking Status
firefox56 --- fix-optional
firefox57 --- fix-optional
firefox58 --- wontfix
firefox59 --- fix-optional

People

(Reporter: from_bugzilla2, Unassigned)

Details

Attachments

(1 file)

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
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.)
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.