228562 - shift+forward should toggle html/plain text

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Lisa]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

shift+write, shift+reply, and shift+reply all compose a message that is in the
non-default format (be it html or plain text). shift+forward, by extension,
should do the same thing, but doesn't. this problem would not be completely
solved by a toggle html/plain text button on the mail composition window,
because if your default is plain text, then the html information will already be
discarded and hitting the toggle button would not get it back.

Reproducible: Always

Steps to Reproduce:
1. select an email
2. hit shift and click forward
3.

Actual Results:  
mail is composed in default format

Expected Results:  
mail should compose in non-default format

Comment 1

[Mike Cowperthwaite]

This will actually work as expected IF you have the default Forward action set 
to "as attachment."  It fails for Inline.  I call it a bug.

Seamonkey bug 254931.

Comment 2

[Mike Cowperthwaite]

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

Comment 3

[Matthew Hodgson]

Attachment: Propagates shift-click of Forward Inline button to mimedrft.cpp

This is a slightly hacky patch which propagates any shift-clicking of the
Forward button through to the MimeStreamConverter which MsgCreate uses to
create a fake template-mail for inline forwarding.  It builds on the existing
hack to use templating for inline forwarding, rather than fixing it. 

mime_parse_stream_complete() in mimedrft.cpp then acknowledges the potential
format override when converting the source mailformat appropriately, and then
instantiates the appropriate composer window format depending on whether the
end composing type was submitted from XUL.

Some of the required end-format checking code (all the calls to
identity->GetComposeHtml and checking for overriding) can probably be factored
out into a single place now, but I've played it safe to avoid breaking anything
and make the patch more intelligible.

Comment 4

[Matthew Hodgson]

Comment on attachment 192414 [details] [diff] [review]
Propagates shift-click of Forward Inline button to mimedrft.cpp

I'm moving this patch to the core mailnews version of this bug at 
#228562, as it only touches on files in the mailnews/ tree.

Comment 5

[Magnus Melin [:mkmelin]]

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

Comment 6

[Magnus Melin [:mkmelin]]

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

Comment 7

[Joerg Starkmuth]

Is there any work going on regarding this bug? It's still present in Thunderbird 1.5.0.9, and for me it's one really annoying problem I encounter quite often. I'm using plain text as default, and I cannot forward HTML mails without changing my account settings - really tedious. Forwarding as attachment is not an option for me (as probably for most people).

Comment 8

[Brian L]

Me too!  Call me naive, but the logic for constructing both html and text inline forward is all in there (as you can get at it by changing account settings), it's just a matter of using it when *shift-forward* happens.  (Ok, I'm preemptively calling myself "naive".)

Comment 9

[Anders Stedtlund]

Just have to agree, this is a very enoying bug for me. Now running 2.0.0.0 and can't see it's resolved. It has been here some years now.

Comment 11

[Dirk Schoettler]

Hi, for me it's nasty, too.

For "Create" und "Reply" it is great to be able to toggle plain/HTML with Shift plus mouseclick (though an icon would be more obvious to find out...).

And I'm really missing it for "Forward", e.g. when an undelivered mail is returned to me by the server. Then I do _not_ want to edit and format the whole mail again including picture, but only to send it unchanged to an other adress.
Please solve this!

Comment 12

[Erik Harris]

Agree with the above - the priority of this bug should get bumped up.  It has plenty of votes, it should be a pretty straightforward bug, and there was even a patch written back in 2005 for the same problem in the Mozilla Suite, over in Bug 254931.

Comment 13

[Mike Cowperthwaite]

(In reply to comment #11)
> And I'm really missing it for "Forward", e.g. when an undelivered mail is
> returned to me by the server. Then I do _not_ want to edit and format the
> whole mail again including picture, but only to send it unchanged to an other
> adress. Please solve this!

If I understand you correctly, Dirk, you can select the message in the Sent folder, choose Edit As New, and then enter the new address without otherwise changing the message.

Comment 14

[Joerg Starkmuth]

Thanks for the hint - this really works and allows us to maintain the HTML format of received (or sent) messages for forwarding. So at least we have a usable workaround. 

Nevertheless, I see no reason why the same shouldn't be possible by simply selecting Shift-Forward. This is where one would expect it, and it should be really simple to implement (as the functionality is entirely there already).

Comment 15

[Dirk Schoettler]

Hello Mike,
this works for the case I want to send a sent mail again, correct.
But as Joerg says, it doesn't help you to forward HTML-mail you received from somebody else. 

It works for "New" and "Reply", so what major obstacles should exist for "Forward"?

Comment 16

[Joerg Starkmuth]

Actually the workaround also works for received mails. You can use "Edit as new" with any message in any folder. So you can use it for forwarding, too - except that TB does not automatically add the "Fwd:" to the subject.

But it's still just a workaround, not an elegant solution.

Comment 17

[Onno Ekker [:nONoNonO UTC+1]]

This bug is blocking bug 111298 (and the other way round too), because each bug suggests another function for Shift+Forward. Could someone please mark these bugs that way?

IMHO toggling html/plain text makes more sense, because that also happens for reply and compose button. Plus there's other solutions for bug 111298, like the dual menu button from bug 17796.

Comment 18

[Magnus Melin [:mkmelin]]

Not a blocker. Would love a patch though.

Comment 20

[einkauf]

The workaround with "Edit as new" is equally tedious as changing the account settings, because this way you do not get the forwarding-"header" like

-------- Original Message --------
Subject: 	NÖN BauenuW_KW07/ PW_KW09/09_Ecker
Date: 	Thu, 22 Jan 2009 11:44:15 +0100
From: 	anzeigen news <[e-mail]>
To: 	<[e-mail]>

and the Fwd: prefix in the subject.

We get very many emails in a central email-account "office@..." and I have to forward them to the correct persons. I and all others do not write HTML-emails, but I would like to forward these incoming emails in the original format to the correct recipients. That's not possible with Thunderbird (2.0.0.19). In the m oment I redirect these emails with the "Mail Redirect"-plugin, but this covers (is this the right word?) the fact that the redirected email orginally came to to another account (although looking at the message-source would reveal it). So the recipient cannot react and tell the sendet the "right" email-address.

Comment 21

[Renato S. Yamane]

"Edit as new" (Comment #16) is similar as 'Reply to all'.

Problem: If you receive this message with 20 e-mails in "To" field, and need forward to other e-mail, you need delete all 20 e-mails one by one.

I think that "Shift + Forward" is a good choice, as "Shift + Reply" do.

After 5 yers, any plan to do this in Thunderbird 3?

Regards,
Renato

Comment 22

[Herbert Eppel]

Please fix this irritating bug - see discussion at <http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/a6e398598c108426/>

Thank you.
Herbert

Comment 23

[Magnus Melin [:mkmelin]]

Taking.

Comment 24

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

Comment 25

[David :Bienvenu]

Comment on attachment 375623 [details] [diff] [review]
proposed fix

+   * This is needed by libmime for MHTML link processing...the url is the URL.
+   * string associated with this input stream.
+   */

The '.' after the URL makes this not read correctly.

Seems like there should be a way of avoiding this code duplication:

     if (composeHtml)
-      format = nsIMsgCompFormat::HTML;
+    {
+      if (composeFormat == nsIMsgCompFormat::OppositeOfDefault)
+        format = nsIMsgCompFormat::PlainText;
+      else
+        format = nsIMsgCompFormat::HTML;
+    }
     else
     {
-      format = nsIMsgCompFormat::PlainText;
-      /* do we we need to convert the HTML body to plain text? */
-      if (composeFormat == nsIMsgCompFormat::HTML)
-        compFields->ConvertBodyToPlainText();
+      if (composeFormat == nsIMsgCompFormat::OppositeOfDefault)
+        format = nsIMsgCompFormat::HTML;
+      else
+        format = nsIMsgCompFormat::PlainText;

Or maybe just use the ? operator in both places.

You want to use aResult and aOverrideComposeFormat here:

+nsStreamConverter::GetOverrideComposeFormat(PRBool *result)
+{
+  if (!result)
+    return NS_ERROR_NULL_POINTER;
+  *result = mOverrideComposeFormat;
+  return NS_OK;
+}
+
+NS_IMETHODIMP
+nsStreamConverter::SetOverrideComposeFormat(PRBool overrideComposeFormat)

I've tried the various permutations of forward inline with default html, default plain text and it seems to work. So r/sr=me, with nits addressed. Sorry for the delay

Comment 26

[Magnus Melin [:mkmelin]]

changeset:   2622:1e7142a15a27
http://hg.mozilla.org/comm-central/rev/1e7142a15a27

->FIXED

w00t! this sure has been bugging me forever

Comment 28

[David]

Seems that the bug has been re-introduced in 2.22 !!!

Comment 29

[Magnus Melin [:mkmelin]]

First of all, file new bugs for new bugs. 
Second, this bug is for thunderbird, and it does still work fine.