609284 - HTML5 Drag and Drop files only works with Nautilus

Status: RESOLVED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Clémence]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

As a user of Xfce, I noticed the default filemanager thunar does not work with firefox for file drag and drop.

Reproducible: Always

Steps to Reproduce:
1. Create html page containing an element that handles ondrop event.
2. Drop a file on the element using xfce or pcmanfm.
Actual Results:  
The event captured type is "text/x-moz-url" and getData("text/x-moz-url") returns file://... (... being the path of the file I try to drag and drop) and event.dataTransfer.files.length = 0;

Expected Results:  
event.dataTransfer.files.length > 0 and having files i can access.

I'm not sure but I suspect thunar and pcmanfm to send the path of the file rather than the file itself, which is way firefox believes it's an url.
But I think a file:// url should be converted to a file to fix this. There may be another cases where a file:// text is excepted to be converted to a file.

Comment 1

[jni.viens]

Bug confirmed : 

firefox 3.6.13 and firefox 4.0b8
archlinux 64bits running openbox

I tried pcmanfm, thunar and ROX, all 3 failed to upload the file with the proper events, as described above.

After messing up my installation with gnome-desktop, i tested with nautilus and everything worked fine. 

Bug seems to be on firefox' end, because chrome will handle properly files passed from thunar/ROX. Parsing file:// URLs seem to be the proper solution to me as well.

Comment 2

[Tyler Downer [He/Him]]

This bug was reported using a pre-release version of Firefox 4. Now that Firefox 4.0.1 final has been released, can you please update and retest your bug? A fresh profile would be a good starting place to test, 
http://support.mozilla.com/kb/Managing+profiles. If you continue to see the issue, can you please update this bug with your results?

Filter: firefox4prebugsunco

Comment 3

[bryan.christ]

This is definitely still a problem:

- I have tested with every version of Firefox beginning with 3.6 to present (FF8).

- The only File Manager that Firefox seems to work with correctly is Gnome Nautilus.

- I have tested with the last two version of Xubuntu and Lubuntu (Thunar and pcmanfm respectively).

- I _do not_ have this problem with Chrome.

- You can test the problem easily on sites that support DnD upload such as mediafire.com and walgreens.com

Comment 4

[Marin]

I confirm. And Thunar and PCManFM are perfectly supported by Chrom[ium].

Comment 6

[z411]

I also confirm. Tested with Firefox 9 (stable) and Firefox 13 (nightly), and PCManFM. Note that the same behavior occurs when trying to drag-and-drop a file into a plain file <input> in a form. 

Again, latest Chromium works well with PCManFM, either with HTML5 file drag and drop or a form's file <input>.

Comment 7

[Ernesto Domato]

I'd like to let you know that with Gnome Epiphany the DnD features also works fine with Thunar like it does with Chromium so it confirms more that seems to be a bug on Firefox.

Comment 8

[Marti Raudsepp]

Also affects me. Tested mostly on imgscalr.com, but also minus.com and Gmail:

         Firefox  SeaMonkey  Chromium  Epiphany  <-- dropping to
Nautilus   yes      yes        yes       yes
Firefox    yes      yes        yes       yes
gThumb     no       no         yes       yes
Geeqie     no       no         yes       yes
Thunar     no       no         yes       yes
^-- dragging from

Firefox 11
SeaMonkey 2.8
Chromium 18.0.1025.162
Epiphany 3.4.0.1

Using Arch Linux, x86_64, with Gnome 3.4 desktop environment. The picture seems rather clear to me.

Comment 9

[r.i.k]

Is there any chance to have this bug resolved before Firefox 20 ? ;-(

NB: I confirmed this bug from FF4 to FF12, under Gentoo Linux with XFCE as desktop environment, with Thunar, Rox, XFE and gThumb.

I also confirmed the lack of a native drop feature on '<input type="file"/>' (avoiding to open the filepicker dialog), which forced me to write the "EZ Drag-n-Drop" (https://addons.mozilla.org/en-US/firefox/addon/ez-drag-n-drop/). Unfortunately, never integrated into FF by the Mozilla team...

Comment 10

[Marti Raudsepp]

(In reply to r.i.k from comment #9)
> Is there any chance to have this bug resolved before Firefox 20 ? ;-(

Only if you can reproduce it in Windows ;)

Comment 11

[joshg]

Having same issue with chrome.. xubuntu 12.04.. precise.. any luck? resolution?

Comment 12

[Stephan Sokolow]

I can confirm with Aurora 16.0a2 that these applications work as drag-and-drop sources for sites like http://imgscalr.com/:
- Konqueror
- Nautilus

...and these do NOT:
- PCManFM
- Geeqie (An image manager. Formerly GQView)
- Comix (Images come from the /tmp folder it uses to cache archive contents)

All of these sources work in Ubuntu 12.04's build of Chromium 18.0.1025.168.

I've actually just given up on seeing a fix, upgraded my system to 16GiB of RAM, and run Firefox and Chromium side-by-side. (I use Chrome's "Press tab to search" URL completion, old AND new drag-and-drop file uploading, and private browsing window and then paste result URLs into Firefox as needed)

Comment 13

[Thomasy]

Opera 12.01 can support PCManFM.

Comment 15

[Tomasz Kołodziejski [:tomasz]]

Also affects me: 16.0.2 as well as 19.0a1 (today's nightly)

Works:
nautilus/dolphin -> firefox
whatever -> opera
whatever -> chromium

Broken:
thunar -> firefox

Comment 16

[Kevin Brosnan [Ex-Mozilla]]

The last several comments have been me too comments. Please refrain from commenting unless you are working on the bug. 

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 17

[Hugo Osvaldo Barrera]

Bug is still present in Firefox 18.

Any chance we get this fixed anytime soon? Firefox seems to be the only browser which doesn't support drag and drop.

Comment 18

[Kevin Cox [@kevincox:matrix.org]]

I would like to add that (for thunar at least) the file is opened, for example, when dropping it on the youtube upload field firefox opens the video with my media player.  If I drag an HTML file it is rendered in that tab.

Comment 19

[Stephan Sokolow]

(In reply to kevincox.ca from comment #18)
> I would like to add that (for thunar at least) the file is opened, for
> example, when dropping it on the youtube upload field firefox opens the
> video with my media player.  If I drag an HTML file it is rendered in that
> tab.

I believe that's the default behaviour for dragging and dropping when no more sophisticated handler takes effect.

I know that's what happened when I dragged and dropped files from PCManFM onto <input type="file"> fields before I installed the EZ Drag-n-Drop extension to bring Firefox up to parity with Chrome.

Comment 20

[Jan Horak [:jhorak]]

Attachment: Support drag and drop local files from sources which use text/uri-list v1

Patch tries to convert URI to nsIFile. When successful then GetData pass it to caller.

This adds support for drag and drop from Thunar, pcmanfm, gthumb or any other Linux application which use text/uri-list as drag & drop data.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 741860 [details] [diff] [review]
Support drag and drop local files from sources which use text/uri-list v1

Review of attachment 741860 [details] [diff] [review]:
-----------------------------------------------------------------

I think Neil knows this better than I do...

::: widget/gtk2/nsDragService.cpp
@@ +852,5 @@
> +                                            // and calls text-specific operations.
> +                                            // Make a secret hideout here for nsIFile
> +                                            // objects and return early.
> +                                            aTransferable->SetTransferData(flavorStr, file,
> +                                                                           convertedTextLen);

I'm not sure that setting an nsIFile as the data for a kURLMime flavor is correct.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think it would probably make more sense to have nsDOMDataTransfer::GetFiles be responsible for handling kURLMime by checking for a file: URL and if there is one, acquiring the right nsIFile then and there.

Someone more familiar with this code, like Neil I think, should review it, since there may be security issues with that change.

Comment 23

[Jan Horak [:jhorak]]

Attachment: Support drag and drop local files from sources which use text/uri-list v2

Okay, I've redone the patch to avoid creating nsLocalFile. Please have a look.

Comment 24

[Neil Deakin]

This should be done within nsDragService::GetData. The earlier patch wasn't right either though. Instead, you should check for the right data within this block:

  if ( strcmp(flavorStr, kFileMime) == 0 ) {
      gdkFlavor = gdk_atom_intern(kTextMime, FALSE);
      GetTargetDragData(gdkFlavor);
    ....
  }

Currently, the code looks for plaintext and converts it to a file. If this file manager is 
providing url type data only, then this block can just look for that url type as well and return a file in the same manner.

Comment 25

[Jan Horak [:jhorak]]

Attachment: Support drag and drop local files from sources which use text/uri-list v3

Next version attached. Works also in google mail (required adding "Files" to nsDOMDataTransfer::GetTypes method).

Comment 26

[Neil Deakin]

You shouldn't need to change nsDOMDataTransfer at all.

We want the nsDragService::GetData method to return the file in the transferable. This method is passed a transferable which specifies the flavours that the caller can support. It iterates over the supported flavours and GetData then fills in the one that has the best data.

If the caller supports kFileMime, this happens by converting text/plain into a file if possible. All you should need is, within the kFileMime condition block to add an additional check (likely with a loop) for the gTextUriListType.

Your patch however is returning the data for gTextUriListType.
 
718                 if ( strcmp(flavorStr, kFileMime) == 0 ) {
719                     gdkFlavor = gdk_atom_intern(kTextMime, FALSE);

You should be able to verify simply by changing kTextMime here to gTextUriListType. Then, change this to handle both text and urls.

Comment 27

[Jan Horak [:jhorak]]

(In reply to Neil Deakin from comment #26)
> You shouldn't need to change nsDOMDataTransfer at all.
> 
> We want the nsDragService::GetData method to return the file in the
> transferable. This method is passed a transferable which specifies the
> flavours that the caller can support. It iterates over the supported
> flavours and GetData then fills in the one that has the best data.
> 
> If the caller supports kFileMime, this happens by converting text/plain into
> a file if possible. All you should need is, within the kFileMime condition
> block to add an additional check (likely with a loop) for the
> gTextUriListType.
> 
> Your patch however is returning the data for gTextUriListType.
>  
> 718                 if ( strcmp(flavorStr, kFileMime) == 0 ) {
> 719                     gdkFlavor = gdk_atom_intern(kTextMime, FALSE);
> 
> You should be able to verify simply by changing kTextMime here to
> gTextUriListType. Then, change this to handle both text and urls.

This is a bit more complicated. Thunar only supplies 'text/uri-list' which is not handled as 'application/x-moz-file' and it does not go thru nsDOMDataTransfer::GetFiles. Reason is the subsequent call of MozGetDataAt at http://mxr.mozilla.org/comm-central/source/mozilla/content/events/src/nsDOMDataTransfer.cpp#481 look for application/x-moz-file while dragged format is text/x-moz-url. 

We could change format to application/x-moz-file when url starts with file:// maybe in nsDragService somewhere, but I'm little bit lost where to do such change.

Comment 28

[Neil Deakin]

(In reply to jhorak from comment #27)
> This is a bit more complicated. Thunar only supplies 'text/uri-list' which
> is not handled as 'application/x-moz-file' and it does not go thru
> nsDOMDataTransfer::GetFiles. Reason is the subsequent call of MozGetDataAt
> at
> http://mxr.mozilla.org/comm-central/source/mozilla/content/events/src/
> nsDOMDataTransfer.cpp#481 look for application/x-moz-file while dragged
> format is text/x-moz-url. 

Let me explain what GetData does more directly. GetData is called with a format that the caller is requesting and supplies the appropriate data if it is supported. In this case, we are asking for application/x-moz-file. If we are asking for application/x-moz-file then GetData should supply an nsIFile if there's supposed to be one in there.

Because we want to alter the normal behaviour on gtk only, GetData should pretend that a file exists even though only text/uri-list is present. Thus, if flavorStr is application/x-moz-file, it should extract a file from the url.  

That's exactly what the code at line 718 is already doing, but for kTextMime. You just need to do the same thing for text/uri-list, as you describe in your next comment.

I also realized that you probably need to change IsDataFlavorSupported as well to indicate that application/x-moz-file is supported when only the url is present.
  
> We could change format to application/x-moz-file when url starts with
> file:// maybe in nsDragService somewhere, but I'm little bit lost where to
> do such change.

Comment 29

[Yet Ding]

I apologise for maybe asking a dumb question. I am not entirely sure whether my problem is related to this bug at all.

I am using Zotero Standalone Reference Manager which is build on xulrunner. On Windows I can drag the URL from the browser (Chrome Browser with Zotero connector extension) into the Zotero window and then Zotero is adding the related file (either web page or PDF) to my collection.

This, however, does not work on Linux. If I am dragging the URL and dropping it into the Zotero window nothing happens. Yet if I drag the same URL to for example Gnome Terminal the URL gets copied into the terminal window.

Which of the programs is hindering me importing a file from the browser to Zotero?

There is already a discussion in the Zotero forums on that. Maybe it is of help:

https://forums.zotero.org/discussion/28097/chrome-zotero-connector-save-zotero-snapshot-from-current-pdf-page/#Item_24

Comment 30

[Jan Horak [:jhorak]]

Attachment: Support drag and drop local files from sources which use text/uri-list v4

Thanks for the explanation. The problem was in IsDataFlavorSupported. Attaching another patch, I'm not sure if any additional check is needed. I did some rudimentary testing and it works fine.

Comment 31

[Jan Horak [:jhorak]]

(In reply to quidam from comment #29)
> I apologise for maybe asking a dumb question. I am not entirely sure whether
> my problem is related to this bug at all.
> 
> I am using Zotero Standalone Reference Manager which is build on xulrunner.
> On Windows I can drag the URL from the browser (Chrome Browser with Zotero
> connector extension) into the Zotero window and then Zotero is adding the
> related file (either web page or PDF) to my collection.
> 
> This, however, does not work on Linux. If I am dragging the URL and dropping
> it into the Zotero window nothing happens. Yet if I drag the same URL to for
> example Gnome Terminal the URL gets copied into the terminal window.
> 
> Which of the programs is hindering me importing a file from the browser to
> Zotero?
> 
> There is already a discussion in the Zotero forums on that. Maybe it is of
> help:
> 
> https://forums.zotero.org/discussion/28097/chrome-zotero-connector-save-
> zotero-snapshot-from-current-pdf-page/#Item_24

It depends on from what application you dragging the file. I use my customized demo of dnd to check which targets source application provides: 
http://xhorak.fedorapeople.org/dragtargets.py 
Drag the file to small window which is spawn by dragtargets.py script and check output in terminal. If only 'text/uri-list' is provided, this patch could help you.

Comment 32

[Neil Deakin]

Comment on attachment 768270 [details] [diff] [review]
Support drag and drop local files from sources which use text/uri-list v4

Review of attachment 768270 [details] [diff] [review]:
-----------------------------------------------------------------

That looks better. Thanks.

Comment 33

[Yet Ding]

> It depends on from what application you dragging the file. I use my customized demo of dnd to > check which targets source application provides: 
> http://xhorak.fedorapeople.org/dragtargets.py 
> Drag the file to small window which is spawn by dragtargets.py script and check output in 
> terminal. If only 'text/uri-list' is provided, this patch could help you.

Thank you!

I just dragged and dropped a PDF opened in Chrome Browser from the URL bar to your dragtargets.py window and it indeed provides me 'text/uri-list' but also more:

Screenshot: http://i.imgur.com/nQhpSSW.png

Will it still work?

How to I apply the patch? Do I have to compile Zotero Standalone with that patch?

I appreciate any help.

Comment 34

[Jan Horak [:jhorak]]

(In reply to quidam from comment #33)
> > It depends on from what application you dragging the file. I use my customized demo of dnd to > check which targets source application provides: 
> > http://xhorak.fedorapeople.org/dragtargets.py 
> > Drag the file to small window which is spawn by dragtargets.py script and check output in 
> > terminal. If only 'text/uri-list' is provided, this patch could help you.
> 
> Thank you!
> 
> I just dragged and dropped a PDF opened in Chrome Browser from the URL bar
> to your dragtargets.py window and it indeed provides me 'text/uri-list' but
> also more:
> 
> Screenshot: http://i.imgur.com/nQhpSSW.png
> 
> Will it still work?
> 
> How to I apply the patch? Do I have to compile Zotero Standalone with that
> patch?
> 
> I appreciate any help.
You could try the patch. I meant to check the terminal, not the test window. The terminal contains also actual data which is dragged in. If you're using nautilus to drop file to your app this patch most likely won't help you.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/357ca015db90

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/357ca015db90

Comment 37

[Alexander]

I have got the same Problem under Windows. 

In Firefox 25.0 (Linux) the problem is resolved.
In Firefox 25.0.1 (Windows) the problem still exists. 

When using a dragging from a Programm (here i've got Groupwise 2012 Java Client) with File Drag Type text/uri-list Firefox dont list the file in the datatransfer object.

Please change Platform to linux AND Windows

Comment 38

[Kevin Brosnan [Ex-Mozilla]]

File a different bug. There is no expectation that a Redhat engineer is going to care about a random Windows file manager.