532131 - Unable to forward messages (charset="")

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Gregory Wallace]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091121 Lightning/1.0pre Thunderbird/3.0

When I attempt to forward a message, either from the preview pane or from the tab that opens for the actual message, the same thing happens.  I get a blank email with no body and no addresses to send too.

Reproducible: Always

Steps to Reproduce:
1. Click Forward button (preview pane / full email tab)
2. New email appears
3. Checking over email message and address.
4. No message in body of email.
5. No addresses in send / CC / BCC


Expected Results:  
Should populate the addresses with those from original email.  The body of the email should be that from the email I am choosing to forward.

I am running on POP3

Comment 1

[Gregory Wallace]

There are no attachments to the email that I am attempting to forward.

Comment 2

[Ludovic Hirlimann [:Usul]]

Does it work if you start Thunderbird in safe mode (http://kb.mozillazine.org/Safe_mode) ?

Comment 3

[rsx11m]

Does it happen with all messages or just specific ones?
If the latter, is there anything they have in common?

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #2)
> Does it work if you start Thunderbird in safe mode
> (http://kb.mozillazine.org/Safe_mode) ?

including with enigmail disabled

Comment 5

[nineteen]

[1] forwarding a message inline that has an attachment will forward the attachment but not the message.
[2] messages without attachment forward inline without problem
[3] message with attachment can forward as attachment no problem
[4] does not happen when replying

Comment 6

[Emerson Prado]

Hi. I had this problem today with Mozilla/5.0 (Windows; U; Windows NT 5.0; pt-BR; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 under Windows 2000 SP4 pt-BR. I tried two messages within one minute (that is, nothing changed) and only one failed.

Comment 7

[Emerson Prado]

Attachment: Source code for mail which had the cited problem when forwarding, with my address changed

OT: this is an address seller. You can send him love letters.

Comment 8

[Emerson Prado]

Attachment: Source code for mail forwarded without problems, with my address changed

Comment 9

[Wayne Mery (:wsmwk)]

Attachment: reply window empty

does your compose windows look something like this?
if not, please attach screen shot

Comment 10

[Emerson Prado]

Yes, exactly!

Comment 11

[Jason Oster (:Parasyte)]

Attachment: Screenshot of subject line

This is a content-type issue, check the header on the "bad" email;

  Content-Type: text/html; charset=""

Notice the empty charset. If you change the charset to "windows-1252", forwarding the message will work as expected.

Also, the subject line is displayed completely broken in the original email (See screenshot).  When setting the charset, I get:

  me@mydomain  -  Conheça nossas Soluções

Comment 12

[Ludovic Hirlimann [:Usul]]

Don't know what the RFC says about the fact that the charset isn't set.

Comment 13

[Emerson Prado]

In this case, couldn't TB show the text even failing to display the special characters? I mean, taking all text as plain ASCII or something? This would be a behaviour close to browsers: FF usually tries one encoding/charset when it doesn't know the correct one and, in the worst case, only special characters are displayed incorrectly or not displayed.

Comment 14

[rsx11m]

> (comment #12) Don't know what the RFC says about the fact that the charset isn't set.

I don't see anything specific on empty charset strings, but if it were missing the default US-ASCII has to be assumed. Thus, for the purpose of robustness, treating charset="" same as a missing charset parameter would be reasonable.

Comment 15

[WADA:World Anti-bad-Duping Agency]

To all problem reporters in this bug except bug opener, and/or comment posters to this bug for additional comments in this bug by other than bug opener:
 
Original problem of this bug is next which is comment #0 of this bug.
(Coomment #0 of this bug) 
> When I attempt to forward a message, either from the preview pane or from the
> tab that opens for the actual message, the same thing happens.
> I get a blank email with no body and no addresses to send too.
> Reproducible: Always
> Steps to Reproduce:
> 1. Click Forward button (preview pane / full email tab)
> When I attempt to forward a message, either from the preview pane or from the
> tab that opens for the actual message, the same thing happens.  I get a blank
> email with no body and no addresses to send too.
> Reproducible: Always
> Steps to Reproduce:
> 1. Click Forward button (preview pane / full email tab)
> 2. New email appears
> 3. Checking over email message and address.
> 4. No message in body of email.
> 5. No addresses in send / CC / BCC
> Expected Results:  
> Should populate the addresses with those from original email.
> The body of the email should be that from the email I am choosing to forward.

Do you see next problem in comment #0?
> I get a blank email with no body and no addresses to send too.
Do you see next problem in comment #0?
> Steps to Reproduce:
> 1. Click Forward button (preview pane / full email tab)
> 2. New email appears
> 3. Checking over email message and address.
> 4. No message in body of email.
> 5. No addresses in send / CC / BCC

Bug summary of this bug, "Unable to forward messages with *empty charset*", is never for generic problem with mail of "*empty charset*".
This bug is apparently not for "display of mail with *empty charset*". This bug is apparently for problem when "forwarding mail which has *empty charset*".

Even if *empty charset* is common, "problem upon forwarding when *empty charset*"(this bug, comment #0) is absolutely different problem from your problem of "something wrong in display of mail of *empty charset*". 
Please never hi-jack bug for different problem from your problem merely by *empty charset* is common in your problem.

If analysis by developers of your problem, "something wrong in display of mail of *empty charset*", is required, open separate bug for your problem after searching B.M.O for already opened bug well via "Advanced Search", please.

Comment 16

[rsx11m]

I don't understand the point of comment #15; I think everybody here is on the same page that forwarding a message with charset="" appears to cause a blank message body in the composition window, this is not for a display issue.

I've rephrased the summary again, it was an attempt to make it more specific. Feel free to adjust it as you think if you continue to disagree with that modification.

Comment 17

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #16)
> I don't understand the point of comment #15;
> I think everybody here is on the same page that forwarding a message
> with charset="" appears to cause a blank message body in the composition window,
> this is not for a display issue.

To rsx11m:
Sorry for my confusion. I probably missed next in Comment #11.
> Notice the empty charset.
> If you change the charset to "windows-1252", forwarding the message will work as expected.

As you say, default by RFC is us-ascii. However, Tb's handling on charset for next cases seems inconsistent.
 - No Content-Type: header
 - Content-Type: ...; with no charset
 - Content-Type: ...; charset="invalid"
 - Content-Type: ...; charset=""
And, it seems to depend on View/Character Encoding/Auto Detect.

AFAIK, "forward in inline" can produce non-blank mail-body text if mail data attached to comment #7, even if invalid binary for defaulted us-ascii or internally chosen ordinal charset is included in Subject: and/or mail body text.
"HTML to text converter" produces null, if Content-Type: text/html; charset=""?
Is this bug for (a) "default composition mode=plain text"? Or (b) "default composition mode=HTML"? Or for both (a) & (b)?

Comment 18

[Ludovic Hirlimann [:Usul]]

Gregory what are your settings wrt to sending emails ?

Comment 19

[Emerson Prado]

BTW: the message is displayed correctly when read - that is, before forwarding. That means TB assumes something, maybe a default charset. IMHO, the edit window could just import those settings from the view pane. Right?

Comment 20

[rsx11m]

TB has to recode the message body for forwarding inline, that's probably where it breaks somehow (different algorithm than rendering for display).

Comment 21

[WADA:World Anti-bad-Duping Agency]

As seen in bug 394322(problem when forward in inline with View/Message Body As/Simple HTML), "forward in inline" is affected by your choice of "View/Message Body As" option.

To all problem reporters in this bug:
What is your choice of "View/Message Body As"?
Does your problem depends on your "View/Message Body As" choice?

Comment 22

[Wayne Mery (:wsmwk)]

can you reproduce this using a current version of thunderbird?

if you are unable to reproduce, please close by setting stats to resolved, and resolution to WORKSFORME or another appropriate setting.

If you are able to reproduce, add new details, and a testcase if one does not already exist in the bug report.

Comment 23

[Joshua Cranmer [:jcranmer]]

RESOLVED INCOMPLETE due to lack of response to last question. If you feel this change was made in error please respond to this bug with your reasons why.