Cannot drag attachment from mail attachment pane to desktop

Bug #381017 reported by komputes
224
This bug affects 63 people
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Fix Released
Unknown
One Hundred Papercuts
Triaged
Medium
Unassigned
SeaMonkey
Fix Released
Unknown
thunderbird (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Ubuntu 9.04
Gnome Desktop 2.26.1
Thunderbird 2.0.0.21

This is regression introduced in Jaunty as it works in Intrepid. Dragging an attachment from the attachment pane to the desktop give the following error:

==
Error while copying
There was an error getting information about "fetch>UID>.voicemail>1784".

The specified location is not supported
==

Mail account is IMAP. This error was shown to seb128 and asac. The expected behavior is that the file is copied to the destination onto which it is dragged.

Revision history for this message
In , thbone (rabo69) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.3) Gecko/20060601 Firefox/2.0.0.3 (Ubuntu-edgy)
Build Identifier: Thunderbird Version 2.0.0.0 (20070326) and also Version 1.5.0.10 (20070306)

If you try to move a attachment via Drag and Drop outside Thunderbird to the desktop or a folder on the PC the drag and drop cursor symbols shows up correctly but no file will be created/moved to this place (This works fine under windows)

(The error shows under Gnome Desktop Ubuntu EdgyEft 6.10 and also under Feisty Fawn 7.04)

Reproducible: Always

Steps to Reproduce:
1. drag an email attachment
2. move the cursor to desktop (press shift or control or nothing - same thing)
3. release mouse button
Actual Results:
no file will be created/moved to the drop place

Expected Results:
the attachment should moved/copied to the drop place (in windows this works fine)

Revision history for this message
In , A S Alam (aalam-deactivatedaccount) wrote :

I can confirm this behavior on my machine on Fedora with KDE.
it ask to create file, but actually has no content from attachment

Revision history for this message
In , Cbook (cbook) wrote :

confirmed on fedora fc 6 with thunderbird 2 release build.

Revision history for this message
In , A S Alam (aalam-deactivatedaccount) wrote :

with trunk build thunderbird-3.0a1.en-US.linux-i686, bug can also be reproduced

Revision history for this message
In , thbone (rabo69) wrote :

bug still exists in new TB 2.0.0.4

Revision history for this message
In , Tokoe (tokoe) wrote :

Created attachment 328330
Allows drag&drop of attachments from message view to desktop

Hej,

this patch allows drag&drop of attachments to the desktop by saving the requested attachment to a temporary file and passing the URL of that file in the drag object. The patch has still two issues: 1) '/tmp' is hard coded... It seems nsIFileUtilities::getTempDirPath() could help here, but how do I instantiate such a component?
2) The name of the temporary file is the same as stored in the attachment, however as it's a temporary file, it should have a unique name (like returned by mktemp(3) under Unix). nsIFileUtilities::newTempFileName() looks promising, but could it be that there is no implementation for that method?

Revision history for this message
In , Frank-u-uu (frank-u-uu) wrote :

See similar Win XP bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=384590

Bug only occurs, when attachment is "large" (> 2MB).

Revision history for this message
In , John Vivirito (gnomefreak) wrote :

Ubuntu has this bug in bug tracker the link for it is
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/151162

Revision history for this message
In , Tokoe (tokoe) wrote :

Created attachment 340309
Use the directory-service for temporary file now

Hej,

the new patch uses directory-service to retrieve the temporary directory instead of hardcoding "/tmp".

Ciao,
Tobias

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

I hope to get to this later this week, sorry about the delay.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Comment on attachment 365417
adapt to HEAD

Mozilla is using hg now, so for future ref, please make patches against hg tip (cvs HEAD is getting old).

The patch doesn't apply cleanly to hg tip, but I've unbitrotted and played with it a bit. Will attach that in a moment.

(no sr needed for mail/ only changes, and I'm not a super-reviewer)

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created attachment 365876
proposed fix (unbitrotted)

Unbitrotted, and creating the file:// url in a safer way.

This patch works, but it's a bit ugly.

Windows doesn't need to do it this way, so I'm thinking the "proper" fix is probably somewhere in the gtk drag service

http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/windows/nsDragService.cpp#559
http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/gtk2/nsDragService.cpp

What do you think?

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

E.g. bug 267426 may be of interest, though it's windows only afaikt.

Revision history for this message
In , Gary-rumblingedge (gary-rumblingedge) wrote :

Moving from General -> MWFE, I was torn between MWFE and Message Reader UI, not so sure, feel free to change though.

We'd need litmus tests to cover this - I'm not sure if MozMill can do DnD out to a non-XUL app (i.e. to Desktop).

Revision history for this message
In , Gary-rumblingedge (gary-rumblingedge) wrote :

(In reply to comment #21)
> (In reply to comment #20)
>
> > We'd need litmus tests to cover this - I'm not sure if MozMill can do DnD out
> > to a non-XUL app (i.e. to Desktop).
>
> Good point. Do you feel about adding them ?

Not at the moment - this is a Linux-only bug AFAICT (Windows is covered somewhere else), and I touch Linux only barely. Mac doesn't seem to have this issue (but has issues with DnD of multiple-selected attachments, but that's another thing altogether).

Revision history for this message
In , Tokoe (tokoe) wrote :

(In reply to comment #18)
> Unbitrotted, and creating the file:// url in a safer way.
>
> This patch works, but it's a bit ugly.
Thanks for the update!

> Windows doesn't need to do it this way, so I'm thinking the "proper" fix is
> probably somewhere in the gtk drag service
>
> http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/windows/nsDragService.cpp#559
> http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/gtk2/nsDragService.cpp
Hmm, but how can I create such a temporary file inside the drag service implementation?

I have only a mailbox:// URL to the attachment there... what component can
I use to extract the attachment from the file, pointed by the mailbox:// URL, and store it in a temporary file?

Or is there another way to retrieve the attachment data somehow? /me is still missing the overview how these things work together :(

Ciao,
Tobias

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Sorry, I don't think i'll be able to help much, and it might not be easy at all... First step is probably to figure out what windows does, and if you can do something similar on *nix.

Revision history for this message
In , Philbaseless-firefox (philbaseless-firefox) wrote :

Windows accepts native com interface iStream for data and our side fills that in. Here's a reference to the object created for windows dnd API compliance.

http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/windows/nsDataObj.cpp#910

I can't do unix but writing the temp file for O/S use should be similiar backend IMO

Changed in thunderbird (Ubuntu):
status: New → Confirmed
Micah Gersten (micahg)
Changed in thunderbird (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in thunderbird:
status: Unknown → New
Changed in thunderbird:
importance: Unknown → Medium
Changed in thunderbird:
status: New → Unknown
Changed in gnome-common (Ubuntu):
status: New → Confirmed
Changed in seamonkey (Ubuntu):
status: New → Confirmed
Revision history for this message
Sparhawk (sparhawkthesecond) wrote :

Still present in Ubuntu 12.04. Again, a link gets created in Nautilus.

Revision history for this message
In , 5-aozilla-e (5-aozilla-e) wrote :

I can confirm this with Thunderbird 14.0 on Ubuntu 12.04 and Unity with all updates applied.

Changed in thunderbird:
importance: Medium → Unknown
Changed in kde-baseapps (Ubuntu):
status: New → Confirmed
Changed in seamonkey:
importance: Unknown → High
status: Unknown → Confirmed
Changed in thunderbird:
importance: Unknown → High
status: Unknown → Confirmed
Revision history for this message
Nick Booker (nmbooker) wrote :

A solution might be to implement the Xdnd Direct Save (XDS) protocol:

 http://freedesktop.org/wiki/Specifications/XDS

Doing the job via XDS means Thunderbird can keep control of the saving process, can react and do extra things if a file of the same name already exists (e.g. prompt the user for a different filename and allow them to cancel), and it doesn't have to create a temporary file to pass to the file manager via a uri link.

The following file managers, at least, support XdndDirectSave0 as drop targets:
 * Nautilus
 * Thunar
 * xfdesktop4
 * rox-filer

I imagine dolphin in KDE4 would support it too.

The file-roller code ( apt-get source file-roller ) and 'gtksavebox.c' in ROX-CLib ( http://sourceforge.net/projects/rox/files/ROX-CLib/2.1.10/ ) are examples of how to to it in C. I can be more specific on request.

In response to comment 88 (by karlt), explicit support isn't needed in GDK: see the source code examples I link to above.

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

I can confirm it's still here, with Thunderbird 17.0, Ubuntu 12.10. Happily you can still "...save as".

Having being reported on 2007-03-24 (see bug#95507), is probably going to be the oldest unfixed confirmed-and-easily-reproduced bug ever... ah no, evolution mailer has some bug older than this. *Sigh*

Revision history for this message
komputes (komputes) wrote :

A quick update after testing this on 13.04 with nautilus 1:3.6.3-0ubuntu5 and thunderbird 17.0.2+build1-0ubuntu1:

Dragging attachments from thunderbird to nautilus creates a link.
The link opens in gedit with the error:
gedit cannot handle imap: locations.

Dragging attachments from thunderbird to nautilus holding Ctrl key gives error:
Error while copying
There was an error getting information about "dir>messageid".
The specified location is not supported

The expected result is that dragging and dropping an attachment should save a copy of the file to the directory on which the file is dropped.

Revision history for this message
Robert Hrovat (robi-hipnos) wrote :

And still there on all desktops since 12.04. Gnome Classic, Unity, Thunderbird latest ...

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

For the records, it's still in 13.04. Why, if it isn't fixed, it will not go away alone.
This, and the multiple bugs in the Funambol sync extension, are the major obstacle to have Linux as the only workstation OS in my job.
Sigh.

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/381017

tags: added: package-qa-testing
Revision history for this message
Paolo Montrasio (paolo-paolomontrasio) wrote :

Still there in Thunderbird 24

Revision history for this message
Ninaw de Leon (neehnahw) wrote :

I'm getting this error when trying to Shift drag from the attachment pane to my Documents folder:

There was an error getting information about "fetch>UID>.INBOX>2525".

Thunderbird 17.0.8

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

Still here. Ubuntu 13.10, TB 24.

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

Maybe we can try to add this bug to the 100 papercuts project. I think it fits...

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

Hi, hundredpapercuts developers: I do not know if this bug fits the "easily fixable" part, but it's undeniably a very annoying papercut bug (you can live without drag and drop attachment from you *default* mailer, but still, the expected behavior is that it should work).
On the other end... this bug it has been here with us so many years that maybe is really impossible to fix.

Revision history for this message
Sparhawk (sparhawkthesecond) wrote :

This bug is a regression, so I doubt it's impossible to fix.

Changed in hundredpapercuts:
status: New → Triaged
importance: Undecided → Medium
no longer affects: gnome-common (Ubuntu)
no longer affects: kde-baseapps (Ubuntu)
no longer affects: seamonkey (Ubuntu)
Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

@Paolo: sadly, it's probably true. I suppose we all got to grip with it (I just stopped trying it and right-click and save, you know, even in other mailer) but it is a very nasty (and, let me say, discreting) bug to have around for so much time.

Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

s/discreting/discrediting/ in the last message.

Revision history for this message
In , ssameer (ssameer) wrote :

I am using Thunderbird 24.5.0 on OpenSuse 13.1 with KDE 4.13.0. Trying to Drag and Drop an attachment to the Dolphin file manager only shows a menu for "link" (no copy). Clicking on "link" creates a .desktop file with a link to the attachment in the message. Clicking on the link just opens an empty location - the attachment does not open. It would be good if this behaviour is fixed.

Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

If I can chime in with a comment to the developers (if anyone is listening here): I am used to never use drag and drop of attachment on TB now, given the really broken behavior.

Suggestion: ditch the thing completely. Remove drag and drop. For good.

It's so broken it is more a danger(1) than any other thing, and it is not so necessary in the end, you can live with "save as..." and company. I suppose that a bug like that not fixed in 7 years means it's too complex to fix; let's accept it and move on. Leaving an half-baked functionality is much worse than not having it.

(1) because sometime it *seems* to work; it creates an icon from which the content is not accesible at all, and can lead to data loss for unsuspecting users.

Revision history for this message
In , Dani (damufo) wrote :

+1 Romano Giannetti
Suggestion: ditch the thing completely. Remove drag and drop. For good.

Revision history for this message
In , Milan Knizek (knizek) wrote :

Wow, after several years of not using TB I have recently migrated from Evolution Mail only to find out this stuff does not work yet. What a pity. (Arch Linux, MATE desktop.)

Revision history for this message
In , Jérôme (jerome-bouat) wrote :

I encounter this bug with :
- Thunderbird 52.8.0
- Thunar 1.6.11 (the package depends on libgtk2.0-0 package)
- Debian 9.4 with a Linux kernel

Revision history for this message
In , Dani (damufo) wrote :

The same:
Also I have found this bug with:
- Thunderbird 52.9.0
- Thunar 1.6.11 (the package depends on libgtk2.0-0 package)
- Debian 9.4
- Xfce 4.12

Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

Yes, still here; will not disappear alone.

I still think that the worst problem of this bug is that is _seems_ to work, and can lead to data loss. It would be much better to forbid the drag and drop completely, if fixing it is too difficult.

Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

It seems that the firefox bug (which is listed as a duplicate, I do not think is 100% correct) #396370 has been marked as fixed. Could this be the case for thunderbird also? That would be great...

Revision history for this message
In , Dani (damufo) wrote :

That would be great...
+1

Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

Checked right now with thunderbird 68.2.1 --- the bug is still here. The dropped attachment creates a file which consists of a broken link.

I *suspect* that this bug has been forgot; it seems really strange that, with all the nice things happened to thunderbird in the last couple of years, no one fixed this quite gross "feature..."

Revision history for this message
Romano Giannetti (romano-giannetti) wrote :

Still here in TB 68.2.1. Must be a record...

Really, I suppose this bug has been forgotten... ;-)

Revision history for this message
In , Expert-alexa (expert-alexa) wrote :

This issue is noticed on Windows 10 as well. Windows is updated. TB re-installed and still doesn't work.
Tested a new User Account and still the same.

Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

In version 78.7.1 the behavior is better: still not working, but it raises an error instead of copying an unusable link.
The error is also ok: "drag and drop not supported".

Definitely better!

Revision history for this message
In , Stransky (stransky) wrote :

I can reproduce it with TB91.

Revision history for this message
In , Dani (damufo) wrote :

(In reply to Martin Stránský [:stransky] (ni? me) from comment #104)
> I can reproduce it with TB91.

+1

Revision history for this message
In , Stransky (stransky) wrote :

Managed to update the patch to latest trunk so let's fix this one.

Revision history for this message
In , Stransky (stransky) wrote :

Created attachment 9250020
Bug 377621 [Linux] Support application/x-moz-file-promise mime type by text/uri-list, r?karlt

When application/x-moz-file-promise MIME content is adverised, save the file to /tmp/dnd_file-*/ directory and
offer it as text/uri-list MIME type.

Based on patches by Phil Lacy and Tobias Koenig.

Revision history for this message
In , Pulsebot (pulsebot) wrote :

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/autoland/rev/3b98ceafb59a
[Linux] Support application/x-moz-file-promise mime type by text/uri-list, r=karlt

Revision history for this message
In , Mlaza (mlaza) wrote :
Revision history for this message
In , Shahar Or (mightyiam) wrote :

Thank you!

Changed in seamonkey:
status: Confirmed → Fix Released
Changed in thunderbird:
status: Confirmed → Fix Released
Revision history for this message
In , Romano Giannetti (romano-giannetti) wrote :

I have Manjaro Linux with TB 102, and the problem is still here. When I do drag-and-drop to a Nemo folder I got the icon copied, and when going to Nautilus I still have "Drag and drop not supported", "an invalid drag type was used".

Revision history for this message
In , Dani (damufo) wrote :

Ubuntu 20.04
Thunderbird 102.2.2
Thunar 4.16.10

Not work. Location specified is not compatible.

Revision history for this message
In , Vseerror (vseerror) wrote :

> I have Manjaro Linux with TB 102, and the problem is still here.
>...
> Not work. Location specified is not compatible.

Bugs fixed long ago is not a great place to be reporting current issues. If it reproduces under Help > Troubleshooting Mode then please file a new bug report

Revision history for this message
In , Stransky (stransky) wrote :

Will look at it - still reproducible on TB 102.

Changed in seamonkey:
status: Fix Released → Confirmed
Changed in thunderbird:
status: Fix Released → Confirmed
Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

In the process of [migrating remaining bugs to the new severity system](https://bugzilla.mozilla.org/show_bug.cgi?id=1789259), the severity for this bug cannot be automatically determined. Please retriage this bug using the [new severity system](https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity).

Changed in seamonkey:
importance: High → Unknown
Changed in thunderbird:
importance: High → Unknown
Revision history for this message
In , Stransky (stransky) wrote :

It's because we added text/uri-list but we still support _NETSCAPE_URL so an application can select _NETSCAPE_URL and we provide an url with "mailbox:///" prefix. We should filter out such internal URL.

Revision history for this message
In , Stransky (stransky) wrote :

If we can detect a drop target is a different application (not thunderbird itself) we may alter URL from mailbox:/// to file:/// and copy the file to /tmp.

Revision history for this message
In , Stransky (stransky) wrote :

Created attachment 9302281
Bug 377621 [Linux] Log correctly MIME type conversions r?emilio

Revision history for this message
In , Stransky (stransky) wrote :

Created attachment 9302282
Bug 377621 [Linux] Don't advertise _NETSCAPE_URL MIME type for internal data r?emilio

_NETSCAPE_URL hints target application it should store URL link instead of copy the pointed data.
Don't use that for internal URL (mailbox:/// and similar).

Depends on D161441

Revision history for this message
In , Pulsebot (pulsebot) wrote :

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/autoland/rev/cc7972f31488
[Linux] Log correctly MIME type conversions r=emilio
https://hg.mozilla.org/integration/autoland/rev/0cea06c45ea2
[Linux] Don't advertise _NETSCAPE_URL MIME type for internal data r=emilio

Revision history for this message
In , Ctuns (ctuns) wrote :
Changed in seamonkey:
status: Confirmed → Fix Released
Changed in thunderbird:
status: Confirmed → Fix Released
Revision history for this message
In , Stransky (stransky) wrote :

The D&D is still a bit broken but let's finish it at Bug 1800972. It also adds support for multiple file transfer.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.