drag n drop attachments is broken
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Thunderbird |
Confirmed
|
High
|
|||
thunderbird (Ubuntu) |
Triaged
|
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
NonfreeKernelMo
Package: mozilla-thunderbird 2.0.0.6+
PackageArchitec
SourcePackage: thunderbird
Uname: Linux ddumanis-laptop 2.6.22-14-generic #1 SMP Tue Oct 9 09:51:52 GMT 2007 i686 GNU/Linux
In Mozilla Bugzilla #377621, A S Alam (aalam-deactivatedaccount) wrote : | #1 |
In Mozilla Bugzilla #377621, Cbook (cbook) wrote : | #2 |
confirmed on fedora fc 6 with thunderbird 2 release build.
In Mozilla Bugzilla #377621, A S Alam (aalam-deactivatedaccount) wrote : | #3 |
with trunk build thunderbird-
In Mozilla Bugzilla #377621, Frank-u-uu (frank-u-uu) wrote : | #4 |
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.
In Mozilla Bugzilla #377621, thbone (rabo69) wrote : | #5 |
bug still exists in new TB 2.0.0.4
In Mozilla Bugzilla #384590, Frank-u-uu (frank-u-uu) wrote : | #6 |
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
In Mozilla Bugzilla #377621, thbone (rabo69) wrote : | #7 |
bug still exists in TB 2.0.0.6
ddumanis (dave-davedumanis) wrote : | #8 |
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
NonfreeKernelMo
Package: mozilla-thunderbird 2.0.0.6+
PackageArchitec
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 : | #9 |
Efrain Valles (effie-jayx) wrote : | #10 |
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.
ddumanis (dave-davedumanis) wrote : Re: [Bug 151162] Re: drag n drop attachments is broken | #11 |
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.
>
>
In Mozilla Bugzilla #384590, Nikolay Shopik (shopik) wrote : | #12 |
Confirm with 2.0.0.12 but NOT with trunk version 3.0a1pre (2008040204) - its ok no problem at all.
In Mozilla Bugzilla #384590, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #13 |
Please mark branch only bugs, subject or whiteboard.
In Mozilla Bugzilla #384590, Nikolay Shopik (shopik) wrote : | #14 |
You mean if its reproducible only with trunk but not current?
In Mozilla Bugzilla #384590, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #15 |
Yes, if you mean current=current stable version. Unfortunately bugzilla's version field is not multi select...
In Mozilla Bugzilla #384590, Nikolay Shopik (shopik) wrote : | #16 |
o-right then, I will not touch bugs if they only appears in current stable. Will just comment
Michael Nagel (nailor) wrote : | #17 |
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-
Changed in thunderbird: | |
status: | New → Confirmed |
John Vivirito (gnomefreak) wrote : | #18 |
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:/
Changed in thunderbird: | |
status: | Confirmed → Incomplete |
Michael Nagel (nailor) wrote : | #19 |
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.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #20 |
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/
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) [nsITransferabl
Source File: chrome:
Line: 1627
It seems like the 'application/
Can somebody enlighten me what that flavour is for and why it could be missing?
Ciao,
Tobias
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #21 |
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 nsIFileUtilitie
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). nsIFileUtilitie
In Mozilla Bugzilla #384590, Frank-u-uu (frank-u-uu) wrote : | #22 |
Problem still exists in 2.0.0.14 and MS XP SP3.
See similar problem on OS Linux: https:/
In Mozilla Bugzilla #377621, Frank-u-uu (frank-u-uu) wrote : | #23 |
See similar Win XP bug here:
https:/
Bug only occurs, when attachment is "large" (> 2MB).
Fabian Kneißl (fabian-kneissl-web) wrote : | #24 |
Here is the bug upstream:
Rui Boon (ruiboon) wrote : | #25 |
This may be related to by 95507
Rui Boon (ruiboon) wrote : | #26 |
This may be related to bug 95507
Changed in thunderbird: | |
status: | Unknown → Confirmed |
Jakob Unterwurzacher (jakobunt) wrote : | #27 |
- Error while copying. - There was an error getting information about "INBOX>1943".- The specified location is not supported. Edit (62.0 KiB, image/png)
Also experiencing this, even with a new profile.
I'm always getting the error Michael Nagel mentioned - see attached screenshot.
In Mozilla Bugzilla #377621, John Vivirito (gnomefreak) wrote : | #28 |
Ubuntu has this bug in bug tracker the link for it is
https:/
John Vivirito (gnomefreak) wrote : Re: [Bug 151162] Re: drag n drop attachments is broken | #29 |
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://
>
>
Can you please translate the text on the box that you have in screen shot
status confirmed
--
Sincerely Yours,
John Vivirito
https:/
https:/
Linux User# 414246
John Vivirito (gnomefreak) wrote : | #30 |
Changed to cinfirm due to upstream bug that is being worked on at this time.
Changed in thunderbird: | |
status: | Incomplete → Confirmed |
Jakob Unterwurzacher (jakobunt) wrote : | #31 |
The translation is the attachment description, but i will additionally do it line-by-line.
Line-by-line translation of http://
+------
| 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 (ara) wrote : | #32 |
This is still happening in Intrepid:
apt-cache policy thunderbird
thunderbird:
Installed: 2.0.0.16+
Candidate: 2.0.0.16+
Version table:
*** 2.0.0.16+
500 http://
100 /var/lib/
Changed in thunderbird: | |
status: | Confirmed → Triaged |
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #33 |
Hej,
any news on that issue? Is the patch ok for review/superreview?
Ciao,
Tobias
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #34 |
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
In Mozilla Bugzilla #377621, Brian-lu (brian-lu) wrote : | #35 |
Two comments:
1. The patch need to be updated to apply the trunk
2. I still can't DnD my attachment to my desktop
In Mozilla Bugzilla #377621, David-ascher (david-ascher) wrote : | #36 |
(From update of attachment 340309)
dmose isn't building on linux much these days, so switching review to magnus.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #37 |
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 :(
In Mozilla Bugzilla #377621, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #38 |
I hope to get to this later this week, sorry about the delay.
In Mozilla Bugzilla #377621, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #39 |
(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)
In Mozilla Bugzilla #377621, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #40 |
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://
http://
What do you think?
In Mozilla Bugzilla #377621, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #41 |
E.g. bug 267426 may be of interest, though it's windows only afaikt.
In Mozilla Bugzilla #377621, Gary-mozillamessaging (gary-mozillamessaging) wrote : | #42 |
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).
In Mozilla Bugzilla #377621, Ludovic-mozillamessaging (ludovic-mozillamessaging) wrote : | #43 |
(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 ?
In Mozilla Bugzilla #377621, Gary-mozillamessaging (gary-mozillamessaging) wrote : | #44 |
(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).
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #45 |
(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://
> http://
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
In Mozilla Bugzilla #377621, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #46 |
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.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #47 |
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://
I can't do unix but writing the temp file for O/S use should be similiar backend IMO
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #48 |
Created an attachment (id=371844)
fixes url -- needs testing
This is a test patch for unix build. I don't have unix to test so please someone on cc test this.
The url passed as flavour data has 2 '&filename='. This may be a problem with unix DND code and may be the problem here.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #49 |
the filename is unescaped so it should not have spaces or non-alpha char, see
bug 485514
In Mozilla Bugzilla #377621, Yuenhoe (yuenhoe) wrote : | #50 |
(In reply to comment #26)
> This is a test patch for unix build. I don't have unix to test so please
> someone on cc test this.
Tested briefly on my build (which is a little old but I don't think attachment code has changed much). Doesn't work. + cursor appears, appears to start moving on drop, but complains it couldn't find the file to move. Nothing gets dropped.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #51 |
> (In reply to comment #26)
> Tested briefly on my build (which is a little old but I don't think attachment
> code has changed much). Doesn't work. + cursor appears, appears to start moving
> on drop, but complains it couldn't find the file to move. Nothing gets dropped.
would you or anyone with a Linux debug build post a log of nsDragService
export NSPR_LOG_
export NSPR_LOG_FILE=bug377621.log
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #52 |
Created an attachment (id=372531)
fixes url test patch-revised
could someone try this fix of the URL flavor revision. The other patch was on seamonkey not TB so it would not have any effect.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #53 |
in windows the only flavours required for file drop are:
-text/x-moz-url
-application/
-application/
if the x-moz-file-promise is omitted then an internet-type shortcut is created.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #54 |
Tobias
To get this to do backend like windows create a stream from the URI then save the stream as the temp file then send it to the desktop in GTK manner. There may be other code to create a file directly from the URI.
Creating the stream is mozilla common code and the windows-specific backend code does it here which :
http://
That will get windows and GTK to work and hopefully Mac works too, if not we need to do the same there.
This gives us a clean frontend which we can use to DND messages to the desktop.
In Mozilla Bugzilla #377621, Roc-ocallahan (roc-ocallahan) wrote : | #55 |
Maybe Michael can mek sense of this.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #56 |
Created an attachment (id=374754)
Drag&Drop support by widget/gtk2 code
This patch implements drag&drop from thunderbird to the Linux desktop (or file manager) by changing code in widgets/src/gtk2 only.
It makes use of the kFilePromise feature to trigger the mail component to save the attachment to a temporary file whenever the text/uri-list flavor is requested on a drag&drop operation. The url of the temporary file is passed as flavor data then...
Could somebody comment on the code, please? I guess the string conversion can be done easier...
In Mozilla Bugzilla #377621, Roc-ocallahan (roc-ocallahan) wrote : | #57 |
Don't you need to use CreateUnique to ensure that the temp file name doesn't clobber something else?
Instead of indenting a lot, use early exits and a helper function if necessary.
You're assuming the URI is UTF-8, I'm not sure if that's right...
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #58 |
I may not read this correct but does this section make the transfer rely on the text/x-moz-url?
As a request to roc, I would think since a file transfer, like doing this attachment, will never create a shortcut url then this should not depend on it. So we should set it up where only the application/
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #59 |
In the front end, msgHdrViewOverl
Windows gets the url from x-moz-file-
If we don't then we will have the front end doing platform specific stuff without anyway to tell without digging into the backend differences. The least we should do is comment the .js file what is being done.
Windows b/e does all this with essentially the one line of code here.
http://
...then windows native reads the stream. Here in GTK we can write it to the temp file and pass it back in the uri-list.
Also if we stick with this front end way we need to do the same messy stuff in bug 227305.
Or
We can scrap windows method and go back to this implementation for windows. In that way we can drag a txt file to word, or a .cpp file to visual studio or a doc file to word. Which can't be done with the stream. But that's not a big deal, we can always add x-moz-file flavour to tell windows to create a temp file and stick with the stream.
In Mozilla Bugzilla #377621, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #60 |
*** Bug 491512 has been marked as a duplicate of this bug. ***
Daniel (hackie) wrote : | #61 |
- nautilus-error.png Edit (14.5 KiB, image/png)
This is still happening in jaunty:
apt-cache policy thunderbird
thunderbird:
Installed: 2.0.0.21+
Candidate: 2.0.0.21+
Version table:
*** 2.0.0.21+
500 http://
100 /var/lib/
Problem is reproduceable every time i try to move an attachment to a file system folder (nautilus) or the desktop.
Nautilus is shoing the following error:
<<
Error while copying.
There was an error getting information about "Inbox".
The specified location is not supported
[Cancel] [Skip all] [Skip] [Retry]
>>
In Mozilla Bugzilla #377621, kai@perfectreign.com (kai-perfectreign) wrote : | #62 |
I like what Phil mentioned about going back to one implementation. Does this have an ETA? I have moved to Thunderbird (from KMail) and have since moved to GNOME (from KDE) and find this frustrating, since d&d works perfectly fine on windows but not on *nix.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #63 |
Created an attachment (id=378778)
this is dnd requirements for windows XP
This will drag and drop attachments from IMAP or local folders to windows XP operating system. As one may notice, it is minimal front end requirements. Mac and GTK should conform to these flavors, except the x-moz-url which may be eliminated in a future bug.
Lets set this to mac o/s as well for testing and get a backend fix for GTK.
I am assuming if this gets reviewed and cleared by roc then Tobias can do the GTK stuff.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #64 |
Created an attachment (id=379435)
Drag&Drop support by widget/gtk2 code with streams
The new version uses streams instead of kFilePromiseUrl. However there are some outstanding issues (temporary files are not removed, too many files generated) that needs fixing, so this patch is a working proof of concept ;)
In Mozilla Bugzilla #377621, Roc-ocallahan (roc-ocallahan) wrote : | #65 |
I assume the patch in comment #40 is not supposed to be checked in until Mac and GTK drag-drop implementations support sending URL contents to streams.
But I'm not really sure if this is the right way to go. Neil Deakin is the best person for this, I think.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #66 |
Another option that may not be cleaner but clearer. In this front end, write to a temp file and transfer it as a 'move' with x-moz-file. Then we may be able to drag attachments to text editors or pdf readers etc.
If x-moz-file transfers aren't working then those are something that probably should be fixed in 1.9.1 whereas the moz-file-promise ones need looking into.
I'm not sure what the need for the x-moz-file-
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #67 |
Created an attachment (id=379666)
Drag&Drop support by widget/gtk2 code with streams
This version of the patch should be functional complete. It creates only
one temporary file for each drag&drop operation and removes all temporary
files at the end, when thunderbird is closed.
Could some of the core developers do a review (coding style, string conversion etc.), please?
In Mozilla Bugzilla #377621, Martijn-martijn (martijn-martijn) wrote : | #68 |
(From update of attachment 379666)
You have to specifically ask review to someone to get a review. I don't know if Robert is the correct person to review this (probably not), but hopefully he can point to someone who is more suited to review the patch.
In Mozilla Bugzilla #377621, Enn (enndeakin) wrote : | #69 |
What is this patch trying to accomplish? If you're expecting the operating system to handle the data as a file, you should be using a file promise or file type. When using the url type, it is up to destination application to retrieve it, we shouldn't be creating it for them.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #70 |
(In reply to comment #46)
> What is this patch trying to accomplish? If you're expecting the operating
> system to handle the data as a file, you should be using a file promise or file
> type.
That doesn't work... und Linux the desktop/filemanager expects that the file is passed as text/uri-list flavour and the desktop/filemanager is responsible to copy
the file to the correct destination.
> When using the url type, it is up to destination application to retrieve
> it, we shouldn't be creating it for them.
How should the destination application access the internal data of thunderbird
if it gets only a mailbox:// url passed? ;)
Now, we have to use the defined standards here...
Ciao,
Tobias
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #71 |
Per comment #46, in the backend if it receives the filepromise flavours it can still convert the data to the text/uri-list and do its thing.
In windows the x-moz-url flavor creates a link file of 'internet shortcut' type. If this is correct other o/s should do the same.
If we use the x-moz-file type then the front ends need to do the work outputting to a temp file and passing data as nsIFile per spec. That would facilitate drag and drop to other apps which can receive temp files but not streamed data. The temp file can still be deleted and the other app notes it and gives its user the option to save it.
Ideally, we should use the best of both worlds. This is data not a file and should use filepromise but in backend the data should be offered as both and either streamed or a file made as requested by the target.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #72 |
(From update of attachment 379666)
>+ nsCOMPtr<
>+ rv = aTransferable-
>+
to comply with comment #46 can we make this kFilePromiseURLMime
>+ nsPrimitiveHelp
>+ data,
>+
and here
the url should be in the data for x-moz-file-
>+ if (strcmp(mimeFlavor, gTextUriListType) == 0 && !mTempFileCreated) {
>+ nsCOMPtr<nsIFile> tmpDir;
a check for kFilePromiseURLMime needed
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #73 |
Created an attachment (id=386466)
Drag&Drop support by widget/gtk2 code with streams
This version of the patch uses kFilePromiseURLMime again as suggested by Phil in #49.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #74 |
(From update of attachment 386466)
I think roc is the reviewer name to set here.
Here's my notes from what I can compare to windows version. I don't have linux to check further than that.
>+ mTempFileCreated = PR_FALSE;
don't quite follow its need, but that may be me.
>+nsresult GetAttachmentDe
maybe use 'GetDownloadDet
>+ // check if text/x-moz-url is supported.
did you mean application/
>+ // The desktop or file manager expects for drags of attachments the
>+ // text/uri-list flavor set to a temporary file that contains the
>+ // attachment.
>+ // We open a stream on the mailbox:// url here and save the content
>+ // to file://
>+ // as text/uri-list flavor.
again, attachments are only one use. 'promise-file' or 'promise-file data' for clarity, and mailbox:// could be other handler <protocol>://
>+ // build the file://
>+ tmpDir-
>+ tmpDir-
don't know how much 'naming' needs to be added to file name for linux use or obfuscation but I assume CreateUnique would be enough. Again 'attachment' should be more generic if needed at all.
>+ mTempFileCreated = PR_TRUE;
>+ mTemporaryFiles
again mTempFileCreated is set but can't see its use. If it is necessary it may be better set after the outputstream succeeds.
repeating! I'm not a reviewer. my comments are only notes. Use at your or reviewer's discretion.
In Mozilla Bugzilla #377621, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #75 |
Tobias: you need to ask review from a specific person. (Set the review flag to <email address hidden>)
You may want to update the patch according to comment 51 first though.
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #76 |
(In reply to comment #51)
>
> >+ mTempFileCreated = PR_FALSE;
>
> don't quite follow its need, but that may be me.
to clear this point, Tobias indicated that GTK (like windows) tends to call the file creation functions more than once so this prevents multiple copies of the temp file.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #77 |
Created an attachment (id=390806)
New version that removes all references to attachments
Sorry for the late reply, exams at university...
The new patch addresses all issues (references to 'attachment', outdated comments etc.) Phil mentioned in previous comment.
In Mozilla Bugzilla #377621, Roc-ocallahan (roc-ocallahan) wrote : | #78 |
(From update of attachment 390806)
I'll hand this off to our GTK2 superhero
In Mozilla Bugzilla #384590, Dbucher (dbucher) wrote : | #79 |
FYI bug still exists in version 2.0.0.22 (20090605) MS XP
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #80 |
(From update of attachment 378778)
I assume that comment 46 effectively made this obselete.
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #81 |
(From update of attachment 390806)
Thank you for this. The general approach looks good, but some of the finer
details should be touched up.
It makes it much easier for reviewers to understand the changes and work out
which code is being modified when patches show function names and have additional lines of context. This can be done automatically by adding a [diff] section to ~/.hgrc or .hg/hgrc: https:/
>+ // We can not delete the temporary files immediately after the
>+ // drag has finished, because the target application might have not
>+ // copied the temporary file yet. Instead we collect all temporary
>+ // files in mTemporaryFiles array and remove them here in the destructor.
The destination app should not indicate that it is finished until it has
copied the file. This seems to be implied by both the XDND and Motif
protocols:
http://
http://
So it should be safe to delete the temporary files in response to the drag-end
(or drag-failed) signals (in SourceEndDragSe
We don't really want to keep accumulating these files when the application
runs for months and the files would not be cleaned up if the app doesn't get a
chance to shut down nicely.
Did you see any apps that were indicating that they had finished before they
had copied the file?
In GetSourceList():
>+ // check if application/
>+ // If so, advertise text/uri-list.
>+ if (strcmp(flavorStr, kFilePromiseURL
>+ GdkAtom urlAtom = gdk_atom_
>+ GtkTargetEntry *urlTarget =
>+ (GtkTargetEntry *)g_malloc(
>+ urlTarget->target = g_strdup(
>+ urlTarget->flags = 0;
>+ /* Bug 331198 */
>+ urlTarget->info = NS_PTR_
>+ targetArray.
>+ }
It looks like this can be done even when numDragItems > 1.
Though I don't think we want two gTextUriListType targets when both kURLMime
and kFilePromiseURLMime are supported flavours (unless there's a reason why
that won't happen). If both kFilePromiseURLMime and kURLMime flavours are
available, then which should be used in the text/uri-list data? (We won't
know whether the destination wants to copy or link.) Perhaps they are
unlikely to both occur together and just picking one will be fine.
I don't think handling multiple files would be too difficult, but even if you
prefer to only implement this for one file right now, make sure that
SourceDataGet() is consistent with GetSourceList().
In SourceDataGet():
>+ void *tmpData = NULL;
>+ nsresult rv;
>+ nsCOMPtr<
>+ rv = item->GetTransf
>+ ...
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #82 |
(From update of attachment 390806)
>+ tmpDir-
Any reason for g+w here? Is this relying on umask.
>+ rv = NS_NewLocalFile
And does this just use umask?
I guess the destination app will copy permissions from the file.
Often mail is considered private and apps seem to use go-r even if umask is more permissive.
We don't know that this data is mail here, but I think it would be better to err on the side of being private for this data of unknown nature: 0700 for the dir, and 0600 for the file.
In Mozilla Bugzilla #384590, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #83 |
Please try a build from
ftp://ftp.
http://
->WFM per comment 1. Please reopen if you can reproduce with a recent 3.0 build.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #84 |
(In reply to comment #57)
Hej Karl,
> It makes it much easier for reviewers to understand the changes and work out
> which code is being modified when patches show function names and have
> additional lines of context.
Ok, fixed, thanks for the hint!
> >+ // We can not delete the temporary files immediately after the
> >+ // drag has finished, because the target application might have not
> >+ // copied the temporary file yet. Instead we collect all temporary
> >+ // files in mTemporaryFiles array and remove them here in the destructor.
>
> The destination app should not indicate that it is finished until it has
> copied the file. This seems to be implied by both the XDND and Motif
> protocols:
Right, unfortunately the KDE applications have a bug there (well, it is actually a bug/missing feature in Qt) and they return the XDNDFinished signal
too early before they have started copying the file. I talked with the
Qt developers already, however it won't be fixed in near future, therefor
that delayed deleting would be a helpfull workaround.
(See last entry on http://
> We don't really want to keep accumulating these files when the application
> runs for months and the files would not be cleaned up if the app doesn't get a
> chance to shut down nicely.
Is it so common that a Thunderbird app runs for months?
> In GetSourceList():
>
> >+ // check if application/
> >+ // If so, advertise text/uri-list.
> >+ if (strcmp(flavorStr, kFilePromiseURL
> >+ GdkAtom urlAtom = gdk_atom_
> >+ GtkTargetEntry *urlTarget =
> >+ (GtkTargetEntry *)g_malloc(
> >+ urlTarget->target = g_strdup(
> >+ urlTarget->flags = 0;
> >+ /* Bug 331198 */
> >+ urlTarget->info = NS_PTR_
> >+ targetArray.
> >+ }
>
> It looks like this can be done even when numDragItems > 1.
Ok, will check
> I don't think handling multiple files would be too difficult, but even if you
> prefer to only implement this for one file right now, make sure that
> SourceDataGet() is consistent with GetSourceList().
Ok, will have a look.
> In SourceDataGet():
>
> >+ void *tmpData = NULL;
> >+ nsresult rv;
> >+ nsCOMPtr<
> >+ rv = item->GetTransf
> >+ getter_
> >+ &tmpDataLen);
> >+ if (NS_SUCCEEDED(rv)) {
> >+ foundFilePromis
> >+ if (tmpData) {
>
> tmpData is not used.
>
> >+ if (foundFilePromi
> >+ PR_LOG(sDragLm, PR_LOG_DEBUG, ("Transferable i...
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #85 |
(In reply to comment #59)
> (In reply to comment #57)
> > The destination app should not indicate that it is finished until it has
> > copied the file. This seems to be implied by both the XDND and Motif
> > protocols:
> Right, unfortunately the KDE applications have a bug there (well, it is
> actually a bug/missing feature in Qt) and they return the XDNDFinished signal
> too early before they have started copying the file. I talked with the
> Qt developers already, however it won't be fixed in near future, therefor
> that delayed deleting would be a helpfull workaround.
> (See last entry on http://
>
> > We don't really want to keep accumulating these files when the application
> > runs for months and the files would not be cleaned up if the app doesn't get a
> > chance to shut down nicely.
> Is it so common that a Thunderbird app runs for months?
I assume mail apps tend to get run continuously (rather than started and quit
repeatedly) so that users are notified of new mail, so I hope Thunderbird will
run for months.
I don't know but I wonder whether or not the app shuts down cleanly when the X
session is ended.
This could be used by any app of unknown function too.
I think deleting the file on a timer could be suitable workaround. (It would
still need to be deleted on exit as well, assuming the timer is not guaranteed
to run before exit.)
Either a glib timer (g_timeout_add? - beware we need to support glib-2.12.x) or
nsITimer should be helpful.
http://
Once the destination has a file handle, it should be safe to unlink, but it
could take a little while for the destination to get a file handle if it
prompts the user for anything. I guess a timeout of a few minutes should be
suitable.
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #86 |
Just a record of my investigation into XDS:
I looked at the possibility of using the Direct Save Protocol (http://
However, I can't see how GTK apps could easily implement this protocol because
GDK doesn't support XdndActionDirec
(October 26, 2000) but I don't know why it's needed. Further, even if this
action could be provided, it would be difficult for destinations not
supporting XDS to know how to fall back to text/uri-list given the
unrecognized action.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #87 |
(In reply to comment #57)
Hej Karl,
> In GetSourceList():
>
> >+ // check if application/
> >+ // If so, advertise text/uri-list.
> >+ if (strcmp(flavorStr, kFilePromiseURL
> >+ GdkAtom urlAtom = gdk_atom_
> >+ GtkTargetEntry *urlTarget =
> >+ (GtkTargetEntry *)g_malloc(
> >+ urlTarget->target = g_strdup(
> >+ urlTarget->flags = 0;
> >+ /* Bug 331198 */
> >+ urlTarget->info = NS_PTR_
> >+ targetArray.
> >+ }
>
> It looks like this can be done even when numDragItems > 1.
>
> Though I don't think we want two gTextUriListType targets when both kURLMime
> and kFilePromiseURLMime are supported flavours (unless there's a reason why
> that won't happen). If both kFilePromiseURLMime and kURLMime flavours are
> available, then which should be used in the text/uri-list data? (We won't
> know whether the destination wants to copy or link.) Perhaps they are
> unlikely to both occur together and just picking one will be fine.
So what shall I do? Checking whether an kURLMime/
> I don't think handling multiple files would be too difficult, but even if you
> prefer to only implement this for one file right now, make sure that
> SourceDataGet() is consistent with GetSourceList().
What exactly do you mean with consistent?
> >+ // remove and re-add the text/uri-list flavor to discard any previous
> >+ // data of that flavor
> >+ item->RemoveDat
> >+ item->AddDataFl
> >+
> >+ // set the file://
> >+ item->SetTransf
>
> The side-effect of modifying the transferable here doesn't feel right to me.
> The transferable is an app-internal reference to the data, while the external
> uri list, generated here for the GtkSelectionData for other apps, is likely to
> be different. (Internally the data can be referenced from the original URI,
> rather than from the file intended for external use.)
So how can I return the url of the temporary file instead of changing the transferable?!?
Ciao,
Tobias
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #88 |
(In reply to comment #62)
> (In reply to comment #57)
> > If both kFilePromiseURLMime and kURLMime flavours are
> > available, then which should be used in the text/uri-list data? (We won't
> > know whether the destination wants to copy or link.) Perhaps they are
> > unlikely to both occur together and just picking one will be fine.
> So what shall I do? Checking whether an kURLMime/
> exists and only create a new gTextUriListType entry if not?
In GetSourceList() when numDragItems > 1, gTextUriListType is the only target
that will be supported, so it's fine to break from the loop when the first is
added.
The real decision will be in SourceDataGet() (or CreateUriList) when choosing
whether to provide the uri from the kFilePromiseURLMime or kURLMime flavor. I
don't know what the right answer is. I'd be happy with even just a comment
indicating that it is not clear which is better.
> > make sure that SourceDataGet() is consistent with GetSourceList().
> What exactly do you mean with consistent?
It's probably enough to make sure that SourceDataGet does
gtk_selection_
can't remember but I was probably also thinking that data should not be set
for targets that were not advertised, but that principal doesn't appear to be
satisfied in current code anyway.)
> So how can I return the url of the temporary file instead of changing the
> transferable?!?
Return it using gtk_selection_
probably need some modification.
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #89 |
Created an attachment (id=403730)
Patch that addresses the problems from previous review
The new patch has the following improvements
- uses a timer to delete the list of temporary files
- uses gtk_selection_
- code that creates temporary file is located in separated method
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #90 |
(From update of attachment 403730)
>diff --git a/widget/
>--- a/widget/
>+++ b/widget/
>@@ -53,26 +53,31 @@
> #include "nsNetUtil.h"
> #include "prlog.h"
> #include "nsVoidArray.h"
> #include "nsPrimitiveHel
> #include "prtime.h"
> #include "prthread.h"
> #include <gtk/gtkinvisib
> #include <gdk/gdkx.h>
>+#include <unistd.h>
> #include "nsCRT.h"
>
> #include "gfxASurface.h"
> #include "gfxXlibSurface.h"
> #include "gfxContext.h"
> #include "nsImageToPixbuf.h"
> #include "nsIPresShell.h"
> #include "nsPresContext.h"
> #include "nsIDocument.h"
> #include "nsISelection.h"
>+#include "nsDirectorySer
>+#include "nsDirectorySer
>+#include "nsEscape.h"
>+#include "nsString.h"
>
> // This sets how opaque the drag image is
> #define DRAG_IMAGE_
>
> // These values are copied from GtkDragResult (rather than using GtkDragResult
> // directly) so that this code can be compiled against versions of GTK+ that
> // do not have GtkDragResult.
> // GtkDragResult is available from GTK+ version 2.12.
>@@ -141,16 +146,19 @@ nsDragService:
> PR_LOG(sDragLm, PR_LOG_DEBUG, ("nsDragService
> mTargetWidget = 0;
> mTargetDragContext = 0;
> mTargetTime = 0;
> mCanDrop = PR_FALSE;
> mTargetDragData
> mTargetDragData = 0;
> mTargetDragDataLen = 0;
>+ mTempFileCreated = PR_FALSE;
>+ mTimer = do_CreateInstan
>+
> }
>
> nsDragService:
> {
> PR_LOG(sDragLm, PR_LOG_DEBUG, ("nsDragService
> }
>
> NS_IMPL_
>@@ -173,16 +181,36 @@ nsDragService:
> } else {
> NS_NOTREACHED(
> return NS_ERROR_
> }
>
> return NS_OK;
> }
>
>+// nsITimer
>+
>+NS_IMETHODIMP
>+nsDragService
>+{
>+ // We can not delete the temporary files immediately after the
>+ // drag has finished, because the target application might have not
>+ // copied the temporary file yet. Instead we collect all temporary
>+ // files in mTemporaryFiles array and remove them here in the timer event.
>+ PRUint32 count = mTemporaryFiles
>+
>+ while (count > 0) {
>+ --count;
>+ mTemporaryFiles
>+ }
>+ mTemporaryFiles
>+
>+ return NS_OK;
>+}
>+
> // nsIDragService
>
> NS_IMETHODIMP
> nsDragService:
> nsISupportsArray * aArrayTransfera
> nsIScriptableRegion * aRegion,
> PRUint32 aActionType)
> {
>@@ -321,16 +349,18 @@ nsDragService:
> gdk_pixmap_
> return PR_TRUE;
> }
>
> NS_IMETHODIMP
> nsDragService:
> {
> PR_LOG(sDragLm, PR_LOG_DEBUG, ("nsDragService
>+ mTempFileCreated = false;
>+
> return nsBaseDragServi
> }
>
> NS_IMETHODIMP
> nsDragServi...
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #91 |
Oops, sorry, clicked in the wrong place!
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #92 |
(From update of attachment 403730)
Thanks, again! Sorry for the delay on this.
>+ // We can not delete the temporary files immediately after the
>+ // drag has finished, because the target application might have not
>+ // copied the temporary file yet. Instead we collect all temporary
>+ // files in mTemporaryFiles array and remove them here in the timer event.
Can you be more specific about the Qt issue please, so that we will know when
it is fixed and this code can be removed? A link to a bug report would be
ideal.
>+ PRUint32 count = mTemporaryFiles
>+
>+ while (count > 0) {
>+ --count;
>+ mTemporaryFiles
>+ }
A "for" loop would work well here.
>+ mTempFileCreated = false;
Use PR_FALSE for PRBools.
>+nsresult GetDownloadDeta
This function can be static and file style is to put the function name on a
new line.
Can you move this to just above CreateTempFile(), where it is used, please?
>+ NS_ENSURE_
NS_PRECONDITION is better here. It is a debug-only check; it shouldn't be
necessary to check in production code.
>+ NS_ENSURE_
Consensus seems to be to deprecate NS_ENSURE_TRUE, and I agree:
http://
Instead, use something like:
if (!srcUrlPrimitive)
return NS_ERROR_FAILURE;
>+ mTimer->Cancel();
>+ mTimer-
>+ NS_DND_TIMEOUT,
>+ nsITimer:
This looks like a sensible place to cancel the previous timer.
A better place to start the timer would be SourceEndDragSe
Can you update the comment for NS_DND_TIMEOUT to explain the new use, please?
>+ outputStream-
I think this is the place to check that buffers have been successfully flushed
to disk. (No need to check inputStream-
>+ char hostname[255];
>+ gethostname(
Need to ensure that there is a NUL terminator here.
(Just make the last byte NUL.)
>+ nsCAutoString hostnameStr;
>+ hostnameStr.
>+
>+ fileURL-
The string copy can be skipped by using:
fileURL-
>+ if (strcmp(mimeFlavor, gTextUriListType) == 0) {
>+ PRUint32 i, count;
>+ mSourceDataItem
>+
>+ // check whether transferable contains FilePromiseUrl flavor...
>+ PRBool foundFilePromis
>+ for (i = 0; i < count; i++) {
kFilePromiseURLMime was only advertised (in GetSourceList) as a uri-list when
numDragItems == 1 and only one temporary file will be created, so only
consider providing the temporary file when numDragItems == 1.
Can this block be merged with the previous "strcmp(mimeFlavor,
gTextUriListType) == 0" block?
>+ NS_ConvertUTF16
By making mTempFileUri ...
Eric Li (eric-li-alumni) wrote : | #93 |
- karmic-thunderbird-error.png Edit (15.0 KiB, image/png)
This bug is still not fixed in karmic
apt-cache policy thunderbird
thunderbird:
Installed: 2.0.0.23+
Candidate: 2.0.0.23+
Version table:
*** 2.0.0.23+
500 http://
100 /var/lib/
In Mozilla Bugzilla #377621, Tokoe (tokoe) wrote : | #94 |
Created an attachment (id=411924)
Patch that addresses the issues found on previous review
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?
Michael Schwandt (webmicsch) wrote : | #95 |
It is sad that, after three years, this bug still exist.
Romano Giannetti (romano-giannetti) wrote : | #96 |
Still here. Really disappointing. I suppose all the fun is going on in TB3, but...
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #97 |
*** Bug 428472 has been marked as a duplicate of this bug. ***
Jakob Unterwurzacher (jakobunt) wrote : | #98 |
Just FYI: The bug *is* still in Thunderbird 3.0 (tested the official binary from mozilla.com).
In Mozilla Bugzilla #377621, Karlt (karlt) wrote : | #99 |
(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-
>+ // (http://
Thanks for filing that. That looks like a sensible suggestion (from my
limited understanding of the Qt APIs).
>+ tmpDir-
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.
>+ // start time to remove temporary files
>+ mTempFileTimer-
>+ NS_DND_TIMEOUT,
>+ nsITimer:
so I think this should check mTemporaryFiles
>+ // check whether transferable contains FilePromiseUrl flavor...
>+ PRBool foundFilePromis
>+ PRUint32 i;
>+ for (i = 0; i < numDragItems; i++) {
No need for a loop here as numDragItems == 1.
Michael Schwandt (webmicsch) wrote : | #100 |
Still not working in 10.04 with Thunderbird 3.0.4. Will it ever be fixed? Probably not. :-(
Michael Nagel (nailor) wrote : | #101 |
- Screenshot.png Edit (30.6 KiB, image/png)
lucid now displays an error message when trying to d&d:
Error while copying.
There was an error getting information about "fetch>
The specified location is not supported
In Mozilla Bugzilla #377621, Philbaseless-firefox (philbaseless-firefox) wrote : | #102 |
*** Bug 544738 has been marked as a duplicate of this bug. ***
Changed in thunderbird: | |
importance: | Unknown → High |
Iwan Mota (iwan-ecf) wrote : | #103 |
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-
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 : | #104 |
New Ubuntu Release (10.10), new Thunderbird (3.1.4) same problem.
Ciccio (franapoli) wrote : | #105 |
3.1.6: bug still there. There must be some sort of world guiness record going on.
In Mozilla Bugzilla #377621, Paolo Montrasio (paolo-paolomontrasio) wrote : | #106 |
The bug is still there in Thunderbird 3.1.7 (Ubuntu 10.4)
mdalo (mayel-dalo) wrote : | #107 |
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.
In Mozilla Bugzilla #377621, Lorenzo (lsutton) wrote : | #108 |
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_
An in the show more details:
The specified location is not supported
Lorenzo.
In Mozilla Bugzilla #377621, Paolo Montrasio (paolo-paolomontrasio) wrote : | #109 |
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)
giorgio_fornara (giorgio-fornara) wrote : | #110 |
Bug still there, TB 3.1.8, Ubuntu 10.04
4 years is a true record!
Augustin (g-u-s-g-u-s) wrote : | #111 |
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.
Romano Giannetti (romano-giannetti) wrote : | #112 |
Still here, Ubuntu natty 11.04, unity.
In Mozilla Bugzilla #377621, Mozilla-stukjewebgebeuren (mozilla-stukjewebgebeuren) wrote : | #113 |
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.
;(
Michaël Van de Borne (mikemowgli) wrote : | #114 |
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??
In Mozilla Bugzilla #377621, Romano Giannetti (romano-giannetti) wrote : | #115 |
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.
In Mozilla Bugzilla #377621, O-register (o-register) wrote : | #116 |
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.
In Mozilla Bugzilla #377621, aova (hot-alex-mail) wrote : | #117 |
Bug confirmed, TB 3.1.11 + Ubuntu 10.04 + gnome 2.32.0
In Mozilla Bugzilla #377621, Paolo Montrasio (paolo-paolomontrasio) wrote : | #118 |
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.
In Mozilla Bugzilla #377621, Sagarwal (sagarwal) wrote : | #119 |
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.
In Mozilla Bugzilla #377621, Paolo Montrasio (paolo-paolomontrasio) wrote : | #120 |
Your comment reminds me of http://
In Mozilla Bugzilla #377621, Chris Coulson (chrisccoulson) wrote : | #121 |
*** Bug 605610 has been marked as a duplicate of this bug. ***
Romano Giannetti (romano-giannetti) wrote : | #122 |
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 : | #123 |
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.
Romano Giannetti (romano-giannetti) wrote : | #124 |
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>
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.
Romano Giannetti (romano-giannetti) wrote : | #125 |
Romano Giannetti (romano-giannetti) wrote : | #126 |
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:/
In the open dialog there are no predefined/
Sigh.
In Mozilla Bugzilla #377621, Romano Giannetti (romano-giannetti) wrote : | #127 |
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:/
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.
In Mozilla Bugzilla #377621, Paolo Montrasio (paolo-paolomontrasio) wrote : | #128 |
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.
In Mozilla Bugzilla #377621, Paolo Montrasio (paolo-paolomontrasio) wrote : | #129 |
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,
Romano Giannetti (romano-giannetti) wrote : | #130 |
...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 : | #131 |
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:
Icon=text-html
I desperately hope this gets fixed anytime soon.
Romano Giannetti (romano-giannetti) wrote : | #132 |
Still here with us in Precise Pangolin. Got an affection to this bug, really...
Sigh.
Changed in thunderbird (Ubuntu): | |
importance: | Undecided → Low |
mekolat (mekolat-deactivatedaccount) wrote : | #133 |
same with 12.10 Quantal Quetzal
In Mozilla Bugzilla #377621, 5-aozilla-e (5-aozilla-e) wrote : | #134 |
I can confirm this with Thunderbird 14.0 on Ubuntu 12.04 and Unity with all updates applied.
Marius B. Kotsbak (mariusko) wrote : | #135 |
This is a duplicate of bug #151162.
Marius B. Kotsbak (mariusko) wrote : | #136 |
I mean bug #381017.
I can confirm this behavior on my machine on Fedora with KDE.
it ask to create file, but actually has no content from attachment