Ubuntu

drag n drop attachments is broken

Reported by ddumanis on 2007-10-10
168
This bug affects 32 people
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Confirmed
High
thunderbird (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: thunderbird

Dragging and dropping an attachment produces a draggable icon which, when released to the desktop, disappears. So, it looks like drag n drop is going to work... but it doesn't. Attachments must be saved in other ways (right-click and using open/save dialog box, etc.).

Attachments should either not turn into draggable icons, or else drag 'n' drop attachments should actually work.

ProblemType: Bug
Architecture: i386
Date: Tue Oct 9 20:43:42 2007
DistroRelease: Ubuntu 7.10
NonfreeKernelModules: ath_hal
Package: mozilla-thunderbird 2.0.0.6+nobinonly-0ubuntu1
PackageArchitecture: all
SourcePackage: thunderbird
Uname: Linux ddumanis-laptop 2.6.22-14-generic #1 SMP Tue Oct 9 09:51:52 GMT 2007 i686 GNU/Linux

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

confirmed on fedora fc 6 with thunderbird 2 release build.

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

Similar problem with OS WinXP as well. If you drag the attachment to the desktop you have to keep the left mouse button pressed for some seconds so the attachment is "loaded" (you see a progress bar). Then you can release the button and the attachment is successfull copied. Otherwise (without waiting) an errormessage shows up ("file in use"). You can work with this unconvenience but it is unexpected, not state of the art and contradicts usability a lot (because it took me quite a while to find out).
If you can confirm this behaviour please extend this bug to OS WinXP as well.

bug still exists in new TB 2.0.0.4

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Version 1.5.0.12 (20070509)

If you drag the attachment to the
desktop you have to keep the left mouse button pressed for some seconds so the
attachment is "loaded" (you see a progress bar). Then you can release the
button and the attachment is successfull copied. Otherwise (without waiting) an
error message shows up ("file in use"). You can work with this inconvenience but
it is unexpected, not state of the art and contradicts usability a lot (because
most people won't discover the workaround).

Reproducible: Always

Steps to Reproduce:
1. Quickly drag and drop big attachment (>3 MB) to desktop

Actual Results:
1. Error-Message "File in use", click on "OK" then
2. Download dialog with progress bar appears like the attachment is actually downloaded
3. No attachment is copied

Expected Results:
Copying attachment to desktop without any delay

bug still exists in TB 2.0.0.6

ddumanis (dave-davedumanis) wrote :

Binary package hint: thunderbird

Dragging and dropping an attachment produces a draggable icon which, when released to the desktop, disappears. So, it looks like drag n drop is going to work... but it doesn't. Attachments must be saved in other ways (right-click and using open/save dialog box, etc.).

Attachments should either not turn into draggable icons, or else drag 'n' drop attachments should actually work.

ProblemType: Bug
Architecture: i386
Date: Tue Oct 9 20:43:42 2007
DistroRelease: Ubuntu 7.10
NonfreeKernelModules: ath_hal
Package: mozilla-thunderbird 2.0.0.6+nobinonly-0ubuntu1
PackageArchitecture: all
SourcePackage: thunderbird
Uname: Linux ddumanis-laptop 2.6.22-14-generic #1 SMP Tue Oct 9 09:51:52 GMT 2007 i686 GNU/Linux

ddumanis (dave-davedumanis) wrote :
Efrain Valles (effie-jayx) wrote :

Thabk you for reporting this bug. This issue dates to times prior to the stable release of Ubuntu 7.10 Gutsy Gibbon. Does this issue still persist?

Thanks again for contributing.

Yes, it definitely does persist. Any attachments dragged and dropped
from the "attachment panel" of a thunderbird message (at the bottom)
onto the desktop simply disappear.

Thanks for your attention and your interest in making Thunderbird on
Ubuntu as good and as usable as Thunderbird on Windows or Mac. Good luck
with the bug fix,

Dave Dumanis

Efrain Valles wrote:
> Thabk you for reporting this bug. This issue dates to times prior to the
> stable release of Ubuntu 7.10 Gutsy Gibbon. Does this issue still
> persist?
>
> Thanks again for contributing.
>
>

Confirm with 2.0.0.12 but NOT with trunk version 3.0a1pre (2008040204) - its ok no problem at all.

Please mark branch only bugs, subject or whiteboard.

You mean if its reproducible only with trunk but not current?

Yes, if you mean current=current stable version. Unfortunately bugzilla's version field is not multi select...

o-right then, I will not touch bugs if they only appears in current stable. Will just comment

Michael Nagel (nailor) wrote :

confirming on an up-to-date thunderbird. for most attachments the cursor becomes a copy-here-icon and releasing just does nothing. for some attachments it becomes the ask-me-what-to-do-icon and releasing creates an error - Error while copying. - There was an error getting information about ";section=2".- The specified location is not supported.

Changed in thunderbird:
status: New → Confirmed
John Vivirito (gnomefreak) wrote :

Michael,
When you say up-to-date what version do you mean?
Please dont mark mozilla bugs as confirmed. If you think it should be set to confirmed please add the tag mt-confirm
I have outlined this in our wiki for bug states but it needs to be revised to state it instead of outlined.
Is this IMAP or POP3 or hav eyou tested with botha nd both show same issue.
Can you please try with a brand new profile to see if you can reproduce this issue.
Im having a thunderbird issue atm so i cant test until i fix it but will test on POP3 sometime by the middle of next week but most likely by monday. If i can confirm this i will mark it as confirmed.
HAve you seen this on the upstream bugtracker for Mozilla? Im thinking this is intended that drag and drop is disabled but need to find out first :)

Im not sure if the following is controled by Thunderbird but rather X. Can you please file this bug upstream at https://bugzilla.mozilla.org/. Once filed can you please post the link on this bug report, Please post the link that has a bugnumber in the URL to do this once you have filed it you will see URL doesnt have bugnumber in it please click on the bug number in the bug and it should than spawn page with bug number in URL.

Changed in thunderbird:
status: Confirmed → Incomplete
Michael Nagel (nailor) wrote :

i am using version 2.0.0.14 (20080505) from and completely updated hardy.

i am sorry about marking as confirmed, i did not know you have special guidelines. i have tested only with IMAP. i'll test with a clean profile if i find the time to do so. same thing for upstream bug report.

Hej,

the problem is that thunderbird doesn't provide a text/uri-list flavour that
could be evaluated by the desktop environment to copy the attachment somewhere
else.

One idea would be to save the attachment to a temporary file and pass the url
of that file as a test/uri-list flavour in the drag operation.
To make that feature work for all platforms, a java script based implementation
would be preferred. So can somebody point me to the place in the mozilla sources
where the drag for attachments is started?
 mailnews/base/resources/content/msgHdrOverlay.js:attachmentAreaDNDObserver
sounds promising, however that method seems not to be called when I try to
drag an attachment from the message view.

BTW, when I drag the attachment to the desktop, the JS error console shows the following message:

Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITransferable.getTransferData]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/content/msgHdrViewOverlay.js :: anonymous :: line 1627" data: no]
Source File: chrome://messenger/content/msgHdrViewOverlay.js
Line: 1627

It seems like the 'application/moz-file-promise-url' flavour is missing...
Can somebody enlighten me what that flavour is for and why it could be missing?

Ciao,
Tobias

Created an attachment (id=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?

Problem still exists in 2.0.0.14 and MS XP SP3.
See similar problem on OS Linux: https://bugzilla.mozilla.org/show_bug.cgi?id=377621

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

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

Rui Boon (ruiboon) wrote :

This may be related to by 95507

Rui Boon (ruiboon) wrote :

This may be related to bug 95507

Changed in thunderbird:
status: Unknown → Confirmed

Also experiencing this, even with a new profile.
I'm always getting the error Michael Nagel mentioned - see attached screenshot.

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

Jakob Unterwurzacher wrote:
> Also experiencing this, even with a new profile.
> I'm always getting the error Michael Nagel mentioned - see attached screenshot.
>
> ** Tags added: mt-confirm
>
> ** Attachment added: "Error while copying. - There was an error getting information about "INBOX>1943".- The specified location is not supported."
> http://launchpadlibrarian.net/16098589/thunderbird-dragdrop-error-box.png
>
>
Can you please translate the text on the box that you have in screen shot

 status confirmed

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

John Vivirito (gnomefreak) wrote :

Changed to cinfirm due to upstream bug that is being worked on at this time.

Changed in thunderbird:
status: Incomplete → Confirmed

The translation is the attachment description, but i will additionally do it line-by-line.

Line-by-line translation of http://launchpadlibrarian.net/16098589/thunderbird-dragdrop-error-box.png :
+--------------------------------------------------------------------
| Error while copying.
|
| There was an error getting information
| about >>INBOX>1943<<.
|
| Show additional details
|
| The specified location is not supported
|
| [ Cancel ] [ Skip all ] [ Skip ] [ Retry ]
+--------------------------------------------------------------------

Ara Pulido (apulido) wrote :

This is still happening in Intrepid:

 apt-cache policy thunderbird
thunderbird:
  Installed: 2.0.0.16+nobinonly-0ubuntu2
  Candidate: 2.0.0.16+nobinonly-0ubuntu2
  Version table:
 *** 2.0.0.16+nobinonly-0ubuntu2 0
        500 http://es.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

Changed in thunderbird:
status: Confirmed → Triaged

Hej,

any news on that issue? Is the patch ok for review/superreview?

Ciao,
Tobias

Created an attachment (id=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

Two comments:
1. The patch need to be updated to apply the trunk
2. I still can't DnD my attachment to my desktop

(From update of attachment 340309)
dmose isn't building on linux much these days, so switching review to magnus.

Created an attachment (id=365417)
adapt to HEAD

Adapted to HEAD. Could somebody do a review soon, please?
I really don't want to update the patch here forever :(

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

(From update of attachment 365417)
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)

Created an attachment (id=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?

56 comments hidden view all 136 comments

*** Bug 428472 has been marked as a duplicate of this bug. ***

Just FYI: The bug *is* still in Thunderbird 3.0 (tested the official binary from mozilla.com).

(From update of attachment 411924)
(In reply to comment #68)
> This patch should fix all mentioned issues. Only the 'check that all data are
> flushed' confused me... doesn't Close() flush the stream automatically before
> it closes?

Yes, it tries to, but that may not succeed. Check the return value of
outputStream->Close() to see whether it succeeded.

>+ // (http://bugreports.qt.nokia.com/browse/QTBUG-5441)

Thanks for filing that. That looks like a sensible suggestion (from my
limited understanding of the Qt APIs).

>+ tmpDir->CreateUnique(nsIFile::DIRECTORY_TYPE, 0700);

I think there should be a check for success here before adding to
mTemporaryFiles to be deleted.

The directory is created here, but this function can still fail to set
mTempFileUri (after cancelling the timer) ...

>+ if (!mTempFileUrl.IsEmpty()) {
>+ // start time to remove temporary files
>+ mTempFileTimer->InitWithCallback(static_cast<nsITimerCallback*>(this),
>+ NS_DND_TIMEOUT,
>+ nsITimer::TYPE_ONE_SHOT);

so I think this should check mTemporaryFiles.Count() instead of mTempFileUrl.

>+ // check whether transferable contains FilePromiseUrl flavor...
>+ PRBool foundFilePromiseFlavor = PR_FALSE;
>+ PRUint32 i;
>+ for (i = 0; i < numDragItems; i++) {

No need for a loop here as numDragItems == 1.

Michael Schwandt (webmicsch) wrote :

Still not working in 10.04 with Thunderbird 3.0.4. Will it ever be fixed? Probably not. :-(

Michael Nagel (nailor) wrote :

lucid now displays an error message when trying to d&d:

Error while copying.
There was an error getting information about "fetch>UID>.INBOX.XXXXX>209".
The specified location is not supported

*** Bug 544738 has been marked as a duplicate of this bug. ***

Changed in thunderbird:
importance: Unknown → High
Iwan Mota (iwan-ecf) wrote :

Same issue here, cannot drag-n-drop attachments from Thunderbird (3.0.8) to Nautilus folder (Lucid 10.04, 2.6.32-25-generic #44-Ubuntu).

The difference is I get a question-mark icon when dragging-n-dropping, with "The specified location is not supported" error from Nautilus.

Added info:

This is an IMAP account using davMail (3.8.5-1480) to access an exchange 2007 server email account.
Identical behavior with Gmail IMAP access from Thunderbird - Could this be an imap-related bug with Thunderbird?

Michael Schwandt (webmicsch) wrote :

New Ubuntu Release (10.10), new Thunderbird (3.1.4) same problem.

Ciccio (franapoli) wrote :

3.1.6: bug still there. There must be some sort of world guiness record going on.

The bug is still there in Thunderbird 3.1.7 (Ubuntu 10.4)

mdalo (mayel-dalo) wrote :

With Thunderbird 3.1.7 and Ubuntu 10.10. The icons does not turn into a draggable icon any more. So there is no bug technically but the functionality is still not there. I hope Thunderbird will gain one day the attachments drag'n drop feature for Ubuntu.

I can also confirm this in Thunderbird 3.1.7 on Ubuntu 10.4 (Gnome
With a warning message:
Error while copying.
There was an error getting information about "[folder_name]>[number]".
An in the show more details:
The specified location is not supported

Lorenzo.

Bug still here, TB 3.1.7 + Ubuntu 10.10 + gnome 2.32.0 and almost 4 years since the creation of the bug (2007-04-16)

Bug still there, TB 3.1.8, Ubuntu 10.04
4 years is a true record!

Augustin (g-u-s-g-u-s) wrote :

Ubuntu Maverick Meerkat 10.10 + Thunderbird 3.1.9pre + gnome 2.32.0.

When dragging any and all attachment to the desktop, it doesn't work (the dragged file bounces back to Thunderbird) or gives an error about the location not being supported.

Still here, Ubuntu natty 11.04, unity.

Just so no-one forgets about this bug, I'm happy to announce that Thunderbird 5.0 on Ubuntu 10.10 still has this bug.

;(

ubuntu natty 11.04 i386, thunderbird 3.1.10, bug still here.
Can the team explain us its policy in terms of long-term unsolved bugs? or does nobody cares at all??

Yep, confirmed here too. Quite unnerving, if I may say. It's a 4 years old bug on something that users will notice in the first 5 minutes of usage.

Confirmed using TB 7.0a2 nightlies on OSX Lion, when I drag an attachment to desktop it creates an empty file named "undefined" instead of the expected attachment.

Bug confirmed, TB 3.1.11 + Ubuntu 10.04 + gnome 2.32.0

Still there in Ubuntu 11.04, TB 3.1.12
I'm sure there is some good reason for the fix is taking so long to deliver after that spur of activity back in 2009. It would be appreciated if the developers could explain what is it. Maybe we can think all together about how to remove any hurdle preventing the resolution of this issue.

Repeated comments are not going to help get the bug fixed any faster. Please stop commenting unless you're willing to take on the bug or have a patch.

*** Bug 605610 has been marked as a duplicate of this bug. ***

Can anyone test it on Oneiric? I will if no-one has done it. (I know that repeating comments helps only a little, but if you do not comment the launchpad system will close the bug automatically, and I still think that this bug, and the "unfeature" of not being able of reading a mbox-filled, externally updated directiry, are the two things that stops TB from being the first real decent MUA for Linux).

Ciccio (franapoli) wrote :

I know this is not going to help, but after years of being annoyed by this bug my solution was: uninstall Thunderbird, pass to Evolution and unsubscribe this bug, which I just did. Solved for me, good luck guys.

Ok, tested, it's even worst now. If I drag and drop an attachment, I have a .desktop file created with the following content:

[Desktop Entry]
Encoding=UTF-8
Name=Link to ODT Document.odt
Type=Link
URL=imap://<email address hidden>:143/fetch%3EUID%3E.INBOX%3E361?part=1.2&filename=ODT%20Document.odt
Icon=text-html

The file is not-openable and, even if it were, it's not locally available (and I suppose that the expected behaviour is to have the file available even off-line).

If TB is the new "default" MUA for Ubuntu, I think that *this* bug shuold be solved. I am available to test.

1 comments hidden view all 136 comments

Hmmm... open is broken too. I attached a screenshot (I can't see it now on launchpad, but I have the email confirmation... what's up?) at https://bugs.launchpad.net/thunderbird/+bug/151162/+attachment/2603690/+files/thunderb_att_open.jpg

In the open dialog there are no predefined/associated application for opening the file. You have to "save as" and then open from file manager.

Sigh.

The behaviour changed. Now when I drag and drop, on Ubuntu 11.10, i have a ".desktop" file created with a "link" to the mail object. The problem is that

1) clicking on the icon give the error Could not display "imap://romano%2Egiannetti%40...1.2&filename=13008%202011.pdf".

2) ...and even if I manage to open it (I can, with some opening and cut and paste and based on the fact that the application understand the URI) what happens if I go offline?

So I think it's worst than ever --- before you had an error, now it could seem that the operation succeeded.

Not sure it's worse but it seems not what we are used to.
All mail clients I know (and also Thunderbird) create a new file with a full copy of the attachment. That seems to create a link to the attachment. If wonder what happens if one edits the saved attachment (let's say it's a .doc on .odt) but I bet that it's just a bug, not the intended behavior.

I did a fresh install of Ubuntu 11.10 and installed some alternative desktop environments.
The behavior with the Unity and the GNOME desktops is what Romano describes.
With MATE (the Linux Mint desktop) I get the old error "The specified location is not supported".
That could mean that the error is in how the desktop environment handles the information passed to it by TB,

...and thunderbird is the default mail app in 12.04, and you still can't drag and drop attachment. Sigh.

Uwe Dulz (uwe.dulz) wrote :

Yes, while dragging under Ubuntu 11.10 just a .desktop file is created, referring to an IMAP link. This is of course useless because even if the system would know how to access IMAP links there are no login credentials provided.
Anything else but link creation does not work at all.
I consider this critical.
BTW, drag-and-drop within thunderbird works nicely, and when doubleclicking a file gets correctly copied to /tmp and opened. For drag-and-drop to nautilus or anywhere else this should just go a step further, providing the link to the /tmp location of the file, then leaving the rest up to the system.

For the records, the contents of a .desktop files looks like this (confident content replaced):

[Desktop Entry]
Encoding=UTF-8
Name=Verknüpfung mit [filename]
Type=Link
URL=imap://[email-address]@imap.googlemail.com:993/fetch%3EUID%3E/INBOX%3E2930?part=1.2&filename=[filename]
Icon=text-html

I desperately hope this gets fixed anytime soon.

Still here with us in Precise Pangolin. Got an affection to this bug, really...
Sigh.

Micah Gersten (micahg) on 2012-05-04
Changed in thunderbird (Ubuntu):
importance: Undecided → Low
mekolat (mekolat) wrote :

same with 12.10 Quantal Quetzal

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

Marius B. Kotsbak (mariusko) wrote :

This is a duplicate of bug #151162.

Marius B. Kotsbak (mariusko) wrote :

I mean bug #381017.

Displaying first 40 and last 40 comments. View all 136 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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