It would be nice to be able to drag stuff from the attachment panel to save them, for example drag a file to the desktop to save it there. Tested on Win98 SE with June-01 tip build

Attachment UI, -> Mscott.

Ugh, sorry, I was a bit short... This is mainly for when reading mails. So it's for the attachment-box in 3-pane view, and the attachment-box in standalone mail window. But I see no downside if it working when writing mail aswell, but that isn't IMHO as usefull

Propose All/All.

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

Is this being considered for Mozilla 1.0 ? I realize that it is labelled as an RFE, but for many people (especially Mac users) being able to drag attachments from the email to the desktop is expected behavior.

Marking All/All and removing enhancement because this is expected behaviour on some platforms as well as 4xp

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

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

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

Must have under MacOS...

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

brain dump from pink: <sspitzer> I'm trying to figure out how to <sspitzer> drag attachments from mail message pane to desktop, and make them save as files (not as links) <sspitzer> see http://bugzilla.mozilla.org/show_bug.cgi?id=83803 <sspitzer> the browser needs this too, with images. (4.x mac did this) <pinkHome> there's no support for that yet <sspitzer> is it making us a better drop source? <pinkHome> it's about what info we put into the drag when it begins <pinkHome> there are special flavors that need to be added to the OS so it knows to allow file drops <pinkHome> you'd want to make a "file" flavor that the dragService knows to convert to the appropriate OS flavor for files <pinkHome> then figure out a way to get the file data into the transferable and a way to get the dragService to correctly create the file <pinkHome> you'd need to specify filename, file type/creator, etc <pinkHome> it's tough to do in a nice xp way, but not impossible <sspitzer> since mac has special file requirements (type/creator) that win32 / linux don't, right? <pinkHome> yes <pinkHome> and windows may do the dirtywork of creating the file for you (i'm not certain) whereas on mac i think the dragservice needs to do a lot of that work <pinkHome> i haven't looked at that stuff for a while, so i forget. <pinkHome> just another wrinkle in doing a nice xp impl

windows has an ole fragment file format, .SHB/.SHS Shell Scrap Object File. A scrap file can contain just about anything from a simple text file to a powerful executable program (including a virus). we can use this type as a last resort. linux i think it depends on the target (gnome, kde, something which doesn't believe in desktops...), but for now we can probably ignore that platform. beos as always is mime based, so as long as we use a standard type or a mozilla owned type, we're fine. os/2's desktop is object oriented, so i'm sure an impl wouldn't be too hard. i don't have enough experience w/ qnx photon. but for now we can lump it w/ linux. (qnx is not unix -- sure)

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

I want to add this for thunderbird. Taking.

http://bugzilla.mozilla.org/show_bug.cgi?id=97413 has a lot of information on how this works for dragging images to the desktop. Hopefully we can leverage a lot of this work for windows.

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

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

The only problem with this is that the drag and drop stuff expects the file to be there as soon as it asks us for it. Bug if your attachment is sitting up on an imap server, it takes a long time to download. If you start dragging the attachment to the desktop, then we immediately start downloading the attachment to an OS specified temp file. When you then make the drop, Windows copies the file from the temp file over to the destination of the drop (the desktop in this case). If we have not finished downloading the attachment before you make the drop, you get a windows error saying the "file is already in use". I'm not sure how other apps handle this. But for POP users and small attachments that download quickly, this feature works well with this patch.

Comment on attachment 138597 [details] [diff] [review] thunderbird patch to support dragging attachments to the desktop I'll spin off the bug with the core drag and drop code about dropping the file before we have finished writing it to the OS specified temp file.

Comment on attachment 138597 [details] [diff] [review] thunderbird patch to support dragging attachments to the desktop that's unfortunate about imap. hmm.

Comment on attachment 138669 [details] [diff] [review] updated patch carrying forward david's sr. I just added the following line to make sure the orignal flavor we were adding before this bug fix gets added after all of our new flavors.

fixed. Created Bug #230455 to track the case where you drop an imap attachment before we have finished downloading it.

Ummm... this was reported for Seamonkey, but the patch fixes it for Thunderbird only. Should this really be resolved?

In today's Seamonkey build, under Windows 2000, I can't drag from the attachment panel at all. Used to be, I could drag from the attachment panel to the compose window. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040119 So no, this isn't fixed.

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

confirm comment #26 on mozilla winxp 1.7a 20040208 : it isn't possible any more to drag attachement received to anywhere, including a new message reopening ??

Reopening. Scott, I guess your fix is T-bird only -- can it be integrated into the suite?

re-closing this patch was for both

mscott: but the patch does not work for Seamonkey, at least as two comments from others say and I just confirmed again with a cvs build from yesterday. I'm aware of your patch from 09 Jan 2004 14:15 to "port this from thunderbird", I'm also aware of bug 230455 about problems with IMAP. But also with POP, dragging doesn't even start. (And there is no JS error in case you wonder.)

sounds like this bug is about DRAGGING to the desktop. sounds like it may have broken dragging to a compose window. it has nothing at all to do with "thunderbird" vs. "seamonkey". Let's file a new bug to track the regression.

mscott: (In reply to comment #32) > sounds like this bug is about DRAGGING to the desktop. Sort of: comment #2 clearly states that this is about dragging attached files from the three-pane window to wherever (received attachments that is). > sounds like it may have broken dragging to a compose window. No, it has not. At least as I can see this works for Thunderbird and Seamonkey on Win2k. > it has nothing at all to do with "thunderbird" vs. "seamonkey". Well, what this bug is all about now works for Thunderbird and does not work for Seamonkey. No "vs." thing, it just is not fixed. > Let's file a new bug to track the regression. In case you mean the "compose window" regression mentioned above, I cannot see it. However, I remember that earlier one could drag from the attachment pane. The result was only a link to the mailbox or something, not the attachment as a file, but at least dragging did something. So if you mean this, ok, that's another regression bug (and *might* finally fix this one). If you just want to open another bug for dragging files from the attachment pane to the desktop, then whoever wants to do so, do it (but please mention it here). However: that new bug would be nothing else than this bug here minus many comments (fine with me). The problem/rfe is exactly the same.

As I stated in comment 26, I can't drag from the attachment panel to anywhere; so: *not only* do I not see the purported results of the fix, *but* there is a regression as well. I'm curious what the difference is between my setup and Andreas', since he says he does not see a problem. I just verified that I'm not able to drag from either 3pane or the message window; cursor doesn't even change on click-and-drag on an attachment. This is seen with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040206 Classic theme; POP accounts only; if there's anything else I can supply to help nail the problem down, please let me know.

> I'm curious what the difference is between my setup and Andreas', since he says > he does not see a problem. Huh? "However, I remember that earlier one could drag from the attachment pane." This is the problem I and you are seeing: no drag possible. It doesn't have anything to do with the compose window. Earlier you could drag to any target (but most would produce unwanted results, i.e. links instead of files). Compose window only was a target that happened to work. > I just verified that I'm not able to drag from > either 3pane or the message window; cursor doesn't even change on > click-and-drag on an attachment. Yes, this is the regression I also wrote about. I wrote "So if you mean this, ok, that's another regression bug (and *might* finally fix this one)." and I'm not sure how this is unclear or what I should add. This IS a regression and once it's fixed, the Desktop as a target might/should also work, which would be an improvement compared to before and would finally really fix this bug.

I personally can't see the point of dragging to create a link to the mailbox -- but both behaviours could easily be included by using modifier keys. For the link behaviour, use the modifier keys that signify 'make alias/shortcut' in the OS (eg option + command on OS X)

(In reply to comment #36) > I personally can't see the point of dragging to create a link to the mailbox Do you see anybody else doing so? That's what it did before, I never said it was useful and this bug is about turning it into something useful.

OK, per mscott's request, I've opened bug 233740 about the loss of drag capability.

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

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

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