Unable to drag from attachment panel to save when reading mail

VERIFIED FIXED

Status

defect
VERIFIED FIXED
18 years ago
10 years ago

People

(Reporter: sicking, Assigned: mscott)

Tracking

(Blocks 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ue][usability])

Attachments

(1 attachment, 1 obsolete attachment)

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

Comment 1

18 years ago
Attachment UI, -> Mscott.
Assignee: sspitzer → mscott
OS: Windows 98 → All
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
Summary: [RFE] Unable to drag stuff from attachment panel → [RFE] Unable to drag from attachment panel to save when reading mail

Comment 3

18 years ago
Propose All/All.

Comment 4

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

Updated

18 years ago
Keywords: 4xp

Comment 5

18 years ago
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.

Comment 6

18 years ago
Marking All/All and removing enhancement because this is expected behaviour on
some platforms as well as 4xp
Severity: enhancement → normal
Hardware: PC → All
Summary: [RFE] Unable to drag from attachment panel to save when reading mail → Unable to drag from attachment panel to save when reading mail

Updated

18 years ago
QA Contact: esther → trix

Comment 7

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

Comment 8

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

Updated

17 years ago
Whiteboard: [ue][usability]

Comment 9

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

Comment 10

17 years ago
Must have under MacOS...

Comment 11

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

Updated

17 years ago
Depends on: 155643

Updated

17 years ago
Blocks: 155643
No longer depends on: 155643
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

Comment 13

17 years ago
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)

Comment 14

17 years ago
*** Bug 171209 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

16 years ago
I want to add this for thunderbird. Taking. 
Assignee: mscott → scott
(Assignee)

Comment 16

16 years ago
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.
Status: NEW → ASSIGNED
*** Bug 215989 has been marked as a duplicate of this bug. ***
*** Bug 227916 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 19

16 years ago
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.
(Assignee)

Comment 20

16 years ago
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.
Attachment #138597 - Flags: superreview?(bienvenu)

Comment 21

16 years ago
Comment on attachment 138597 [details] [diff] [review]
thunderbird patch to support dragging attachments to the desktop

that's unfortunate about imap. hmm.
Attachment #138597 - Flags: superreview?(bienvenu) → superreview+
(Assignee)

Comment 22

16 years ago
Posted patch updated patchSplinter Review
Attachment #138597 - Attachment is obsolete: true
(Assignee)

Comment 23

16 years ago
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.
Attachment #138669 - Flags: superreview+
(Assignee)

Comment 24

16 years ago
fixed. 

Created Bug #230455 to track the case where you drop an imap attachment before
we have finished downloading it. 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 25

16 years ago
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.
(Assignee)

Comment 27

15 years ago
*** 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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 30

15 years ago
re-closing this patch was for both
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → FIXED

Comment 31

15 years ago
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.)
(Assignee)

Comment 32

15 years ago
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. 

Comment 33

15 years ago
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.

Comment 35

15 years ago
> 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.

Comment 36

15 years ago
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)

Comment 37

15 years ago
(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.
(Assignee)

Comment 39

15 years ago
*** Bug 237179 has been marked as a duplicate of this bug. ***
*** Bug 185088 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 160862 has been marked as a duplicate of this bug. ***

Updated

10 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.