105676 - "Reply to..." in context menu for email address in headers section of msg viewer

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Morten Nilsen]

This would simplify matters wholly when participating on mailing lists...
let's say we have an email from the list "[e-mail]".
From is "[e-mail]", To is "[e-mail]" and CC is
"[e-mail]"
instead of using "Reply All" it would be great to be able to right-click
one of the email addresses, and selecting "Reply to" (or some such)

I hope this small feature isn't too much job, and can be implemented before at
least 1.0 is branded.

Thanks, Morten

Comment 1

[Håkan Waara]

Try right-clicking the row and choosing "Reply to Sender Only".

Recommending wontfix. At first sight, I think this sounds redundant.

Comment 2

[Morten Nilsen]

What if you want to reply to one of the people on the CC list only?

Comment 3

[Håkan Waara]

Oh, then you can just expand the headers panel, right-click the email and choose
"Compose Mail To ..." 

Is that what you needed?

Comment 4

[Morten Nilsen]

No it is not... 

I want to Reply to someone with quoted text, not send a new message without the
quote...
I think the difference is quite great, don't you?

Comment 5

[Ben Bucksch (:BenB)]

Hakan, Reply != New mail. New mail doesn't have References etc. headers sat.

I think, this is a good idea. CONFIRMing.

However, not for the reason mentioned. I think that Mozilla should have a "reply
to recipients" button, which replies to all recipients, but not the sender. This
would do what you want in most cases.

But for replying to a cced recipient, this could be useful. It certainly makes
at least as much sense as having a "Compose new mail to..." context menu item.

Comment 6

[Pratik]

My 2 cents. A mailreader I used had this extremely useful functionality whereby
you could press Alt-Reply button and it would popup a dialog box with all the
receipients of the message in it. You can select To, CC, BCC for each one of the
receipients and then hit compose mail and it wil compose a reply with the
addresses specified.

Comment 7

[Jesse Ruderman]

If you want to "reply" to the recipients of the original message, just hit 
Reply and remove the sender from the list of recipients of your message.  I 
think this bug should be wontfixed, because right-clicking the sender's address 
in order to reply to his message doesn't make sense to me.

Comment 8

[scottputterman]

reassigning to mscott.

Comment 9

[Morten Nilsen]

I've hacked together a quick patch to (hopefully) implement the context menu item.
My function ReplyToNode is however largely crap, and someone with a clue should
replace it...

I'm not able to compile a working mozilla from my tree for some reason, so if
somebody could test my patch (and add a working function) that'd be swell :)

Comment 10

[Morten Nilsen]

Attachment: Patch to add context menu item

Comment 11

[Morten Nilsen]

Attachment: Improved patch

Comment 12

[Håkan Waara]

You'll need to get jglick's stamp of approval before changing this UI.

Comment 13

[Morten Nilsen]

My current patch adds the context menu item, and selecting that item is equal to
pressing the "Reply" button in mozilla...

I really need some pointers to figure out how to get the reply to go to a
specific email address.
But I think this will be ready to go in once I figure that part out, and I get
all the stamps of approval of course :)

Comment 14

[Morten Nilsen]

Attachment: Even more improved patch

Comment 15

[Morten Nilsen]

This latest patch adds (most of) the c++ code that will be needed to make this work.
I haven't gotten the emailAddress to be put where it should go yet, and I'm
basically stuck.

The root of my problem is my use of PRUnichar in c++ to get the email address
passed into the message params.

But I hope to get this done soon (with a little help)

Comment 16

[Morten Nilsen]

Currently doing some work again on this, thanks to netdemon.

A new patch which, hopefully, will be closer to working on the way.

Comment 17

[Morten Nilsen]

Attachment: Yet better patch

This patch adds the contextual menu, and makes selecting it the equivalent to
pressing Reply. the patch needs some more code to go in to make it work.

Comment 18

[jglick]

Can you attach a screenshot of what the context menu would look like?

Comment 19

[Morten Nilsen]

Attachment: Screenshot of UI

Screenshot of the context menu with new item "Reply To This Email Address"

Comment 20

[Morten Nilsen]

my latest patch appears to be broken again, but I'll wait with making a new one.
When I tried to apply it to my local CVS tree, I got an error saying the last diff
was malformed, so I had to overwrite that file with the one I diffed with.

Comment 21

[Morten Nilsen]

Attachment: the UI changes part of the bug

sorry about doing this, but I thought it might be good to separate the finished

part from the unfinished part.

This patch adds the context menu item, and the JS code to make the reply.
There shouldn't be neccessary with any major changes to this patch, as long as
it
applies.

Comment 22

[Morten Nilsen]

Attachment: This is the C++ part of the patch

This patch is a bit more dubious.
what it generally does, is duplicating the OpenComposeWindow and removes some
parameters and adds a new one. In theory (in my head) this piece of code
_should_
work all the way, but it doesn't ... the To: field is set somehwere between my
function and the window creation. I can't find it anyways.

Comment 23

[Xavier Poinsard]

Isn't bug 45715 http://bugzilla.mozilla.org/show_bug.cgi?id=45715 a solution :
it proposes to add a reply to list button ?

Comment 24

[Morten Nilsen]

Not entirely...
this bug is about adding the ability to reply to any of the addresses from the
email header display specifically...
sure, bug 45715 would solve this bug in many ways (but not all cases, skimming
the top of that bug)...
The reverse is true however, and this bug would solve bug 45715 for as far as I
can see...

Comment 25

[Morten Nilsen]

anyone planning on doing anything with this bug, or should it be reassigned to
[e-mail]?

Comment 26

[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 27

[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 28

[Magnus Melin [:mkmelin]]

Still valid RFE.