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

UNCONFIRMED
Unassigned

Status

()

P5
normal
UNCONFIRMED
a year ago
11 months ago

People

(Reporter: from_bugzilla2, Unassigned)

Tracking

52 Branch
Unspecified
Linux
Points:
---

Firefox Tracking Flags

(firefox56 fix-optional, firefox57 fix-optional, firefox58 wontfix, firefox59 fix-optional)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
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

a year 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.
Component: Untriaged → Drag and Drop
OS: Unspecified → Linux
Product: Firefox → Core
(Reporter)

Comment 2

a year ago
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.)

Updated

a year ago
status-firefox56: --- → fix-optional
status-firefox57: --- → fix-optional
Priority: -- → P5

Updated

11 months ago
status-firefox58: --- → wontfix
status-firefox59: --- → fix-optional
You need to log in before you can comment on or make changes to this bug.