59622 - RFE: Drag Mail to Desktop

Status: RESOLVED DUPLICATE of bug 537448

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Ben Ruppel]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108
BuildID:    2000110804

NS4.x allowed one to drag a message from mailnews onto the desktop, much like
dragging a link to the desktop (or any other location).  On the windows platform
(at least), this resulted in a url link pointing to a file in the Users
direction, using the "mailbox:" protocal, which never worked for me even though
I made netscape my default mail program.

I think we should get the ability to make links to messages in mozilla (and
hopefully it will work for me).

Reproducible: Always
Steps to Reproduce:
None, it's an RFE.	

Actual Results:  RFE

Expected Results:  RFE

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

Fenella, Sheela?

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

I haven't found a DUP for this, so I think we should accept. Severity is now
enhancement.  Sheela, I think this is your area, if not, please re-assign.

Comment 3

[scottputterman]

reassigning to ssu.

Comment 4

[Jesse Ruderman]

I prefer Outlook Express's behavior: dragging a message to the desktop creates a
copy of the message in .eml format.  Many browsers and e-mail clients can handle
this format, and Netscape Navigator 4 and Mozilla Navigator even display some
headers.  In contrast, a link to a mail message is not likely to work for a long
time.  See also bug 26201, Mozilla Mail should register the .eml extension
instead of leaving it for Outlook Express.

Comment 5

[Ben Ruppel]

I see the advantages of recognizing the .eml format, but this just gives us a
copy of the email on your desktop.  I would like double clicking on the desktop
icon to go back to the original mail on the server, so that replying to it or
deleting it would do so on the server.  

Comment 6

[Jesse Ruderman]

Replying would work with .eml, because .eml includes the headers.

Comment 7

[Ben Ruppel]

Yeah, but in mozilla, it doesn't say "replied" next to the original message in
your inbox. 

Just s subtle nuance.

Comment 8

[Peter S. May]

(I refer specifically to Win9x and NT 5.x, but concepts surely apply elsewhere.)

I'm quite amazed that this one hasn't been handled yet -- it's one of only two
or three things I actually don't like about Mozilla Mail. I used to use Outlook
Express and was constantly dragging messages to Desktop (or other local
directories) for a copy of the .eml file (all that is is the entire message
source saved in ASCII format, right?). On the other hand, I could see how a
shortcut back to MailNews would also be handy...

How about allowing the default behavior to be set in prefs, and then giving a
full options context menu on a right-click and drag?

[E.g.: When left dragging a file from one directory to another, the default op
is executed -- usually "Copy Here" -- but a right drag gives an entire options
menu, Copy Here in bold, then Move Here, Create Shortcuts Here, WinZip extract
options if it's a Zip file, et cetera, and finally Cancel.]

Somebody please take another look at this one!

Comment 9

[Mike Cowperthwaite]

xref bug 83803, about dragging attachments to the desktop -- that bug was 
changed from 'enhancement' to 'normal' because it "is expected behaviour on
some platforms as well as 4xp."  Shouldn't that logic apply to this bug as well?

re: the original report, dragging a message over the desktop no longer generates 
a link, it just becomes undroppable.  (Links are still created for dragged 
attachments, viz. 83803.)

Presumably, the implementation of this would not be limited to the desktop, but 
to any file-accepting destination: directory icon, directory window, trash icon 
(bug 101111).

Comment 10

[Mike Cowperthwaite]

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

Comment 11

[OstGote!]

xref TB Bug 227305

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Phil Lacy]

memo to me:
bug 227305

Comment 20

[Phil Lacy]

I'll build SM latest and patch this bug if I can.