Open Bug 485593 Opened 15 years ago Updated 2 years ago

Edit as New includes reference message-id to the original article, as if I had replied or forward the message. Edit as New should ditch such headers

Categories

(MailNews Core :: Composition, defect)

x86
Windows Vista
defect

Tracking

(Not tracked)

People

(Reporter: wsmwk, Unassigned)

References

(Blocks 1 open bug)

Details

Edit as New of newsgroup article includes reference to the original article, as if I had replied or forward the message. Edit as New should ditch all headers of the original message.

1. pick a newsgroup message and do edit as new
2. save as draft
3. view the draft source

actual results:
draft contains References: in header

expected results:
no reference to the original message, nor anything related to any prior messages
this bit me again. 
not surprising, happens also with regular mail.
xref bug 218716
Summary: Edit as New of newsgroup article includes reference to the original article, as if I had replied or forward the message → Edit as New includes reference message-id to the original article, as if I had replied or forward the message. Edit as New should ditch such headers
(In reply to comment #0)
> expected results:
> no reference to the original message, nor anything related to any prior
> messages

Sounds right to me
Sounds like WONTFIX!
If I reedit a message which is a reply, *of course* the references must be kept!
To be more precise: the current implementation is "reedit", the menuitems are "just" badly named. It won't help breaking all stuff depending on this behaviour, but a new command which does as described in comment #0 might prove valuable.
(In reply to comment #3)
> If I reedit a message which is a reply, *of course* the references must be
> kept!

But this is "Edit as New", not reedit.  As I understand it, the features purpose is to take an existing message and send it as if it were a new message written by you.  It seems like including a reference message-id would defeat that purpose.
OS: Windows Vista → All
Hardware: x86 → All
Version: unspecified → Trunk
(In reply to comment #4)
> To be more precise: the current implementation is "reedit", the menuitems are
> "just" badly named. It won't help breaking all stuff depending on this
> behaviour, but a new command which does as described in comment #0 might prove
> valuable.

I see, I wasn't aware of this design.  Not sure how to proceed.
I never thought of it as reedit. Karsten is that really the origins of this function?  I didn't find any references outside the code to anything older than 2007. Anyway, you may be right about breaking functions that depend on this behavior - do we know of any?

Problem is a) there is no other way to get rid of the "history" of the original message, b) I doubt any non-technical users know this is happening to them. One bad effect is that new messages sent with a different subject are threaded to the original message - which is precisely what I want to avoid.

Additionally, I just sent a new message from Template, and the same effect can be observed. IMO this behavior is even worse.
OS: All → Windows Vista
Hardware: All → x86
Version: Trunk → unspecified
(In reply to comment #7)
> I never thought of it as reedit.

What kind of edits are there and how often are they used?
- new mails: empty mail, no dependencies
- reply: empty/quoted text, depends upon mail replied to
- forward: inline/attachment, depends upon mail replied to
- open (edit) message from template/draft folder: "reedit" (=edit as is!) , keep dependencies
- open (edit) existing message from elsewhere: "reedit"

What you are looking for is "new mail, but with body (only) from somewhere else", which kind of violates the expectation that editing a mail would edit this very mail as is and not something else which looks the same on the surface...

> Karsten is that really the origins of this function?

It's how it's implemented and how it makes sense. If I edit a reply because I forgot to CC someone, I don't want to loose the references!

> Problem is a) there is no other way to get rid of the "history" of the
> original message,

Why would you want to do that?
That's a very special case, imo, you could just as well do copy and paste.

> b) I doubt any non-technical users know this is happening to them.

I doubt that. If I edit a reply, it should still be a reply. If I strip the references (or whatever other header), it isn't.

> One bad effect is that new messages sent with a different subject are 
> threaded to the original message - which is precisely what I want to avoid.

When would that happen?
You send the same mail to someone who already was part of the same thread anyway - this doesn't make much sense, even less to break the reply notion.

People are even _replying_ to mails to write _new_ ones and wonder why there're references - that's not uncommon on mailinglists, but still is a lack of understanding, not of the program (modulo confusing option wording, of course).

> Additionally, I just sent a new message from Template, and the same effect can
> be observed. IMO this behavior is even worse.

Again, no.
The mail edited should be edited AS IS. If you save it with references, they should be kept. 

The actual problem here is that our UI doesn't show all headers, not even optionally. _That_ would be a real enhancement.

Don't try to "fix" what ain't broken.
I think this is broken, but do not agree with either Comment #0 nor #7.

There are 3 legitimate uses for "reedit-like" user commands:

1. Reply/forward, this should reference the original and all referenced by the original.  The Reply/Reply All/Forward functions do this nicely.

2. To pick up one of your own messages (or one written for you by an assistant), edit it further and then send it.  This should preserve the references made by the original, but not add a reference to the draft/original itself.  This is how I mostly use the badly named "Edit as new" command.  It could also be seen as a "continue editing after possible premature send", but that is just one usage.  Suggested change: Rename user command to "Edit Again" and make sure the function invoked by that command does not reference the edited message, but keeps the references made by that message.

3. To start a new thread with the "general headers" (From, To, Reply-To etc.) and general body of an existing message as a template.  This should have no references in it.  This should be the default behavior when picking up content from the Templates.  If a separate user command is needed it should be named "Use as Template", with an internal function called "usetemplate".

Another implementation idea could be a general "editas" function which takes a parameter indicating the level of reference preservation, another indicating the desired manipulation of To/From/Cc headers, and a third one taking an optional closure (function+object) that can do additional manipulations such as adding the "Re:" prefix in the subject.
This "feature" should either be renamed to something else, or then the headers should be cleaned up, and the message should be as "A new message" wihout references to the old message. eg the In-Reply-To and References should be removed.
tb: 31.1.1
kernel: 3.16.2-1

i checked 'safe-mode' and 'new profile'. The result is the same.
Blocks: 872469
Tough call. There are arguments for both sides. In some cases you want to re-create the very same message again, in other cases the lazy ones just pick a message that looks vaguely what they want to send again, "edit as new", modify a bit, then send. And boom, it messes up the threading on the other end :-(
Actually, why would you want to re-create the exact same message (including refs)?
The *only* way I have ever used it, is as a template for a new message without having go through the trouble of making a template - which is pointless in one-off cases, and cases where you want to base your "template" from the very most recent version of a particular type of message.  In both of those cases, including message-id is a horrible side effect.
c/which is pointless in one-off cases/making template is pointless for one-off cases/

(my terrible habit of incomplete sentences)
See comment #8:

(In reply to Karsten Düsterloh from comment #8)
> > Karsten is that really the origins of this function?
> It's how it's implemented and how it makes sense. If I edit a reply because
> I forgot to CC someone, I don't want to loose the references!

Not a strong use case, since it you've forgotten someone, you don't want to ship to all the original recipients again, unless you sent the message to the outbox (send later). In fact, there's another use case. I sometimes edit messages in the outbox "as new", and they need to stay intact.

Like with mailing list munging, impossible to change the behaviour without creating an outcry. But we could create a new command or some option/prompt.
Agreed, I don't see the use case of editing a reply to include someone. You'd just reply to the mail and get a followup (reply-to-self).

For outbox, their references need to stay intact, but that's different and "Edit as new" is not what you want, it sounds like. Rather an Edit (make a draft looking like this, and delete the original).
outbox is definitely an explicit exception, where your are likely fixing a bad message
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.