If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Unable to forward messages (charset="")

RESOLVED INCOMPLETE

Status

Thunderbird
Message Compose Window
--
major
RESOLVED INCOMPLETE
8 years ago
6 years ago

People

(Reporter: Gregory Wallace, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [closeme 2012-03-25], URL)

Attachments

(4 attachments)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
There are no attachments to the email that I am attempting to forward.
Does it work if you start Thunderbird in safe mode (http://kb.mozillazine.org/Safe_mode) ?

Comment 3

8 years ago
Does it happen with all messages or just specific ones?
If the latter, is there anything they have in common?
(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
Whiteboard: closeme 2009-12-20

Comment 5

8 years ago
[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

8 years ago
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

8 years ago
Created attachment 422950 [details]
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

8 years ago
Created attachment 422951 [details]
Source code for mail forwarded without problems, with my address changed

Updated

8 years ago
Attachment #422950 - Attachment mime type: application/octet-stream → text/plain

Updated

8 years ago
Attachment #422951 - Attachment mime type: application/octet-stream → text/plain

Updated

8 years ago
Whiteboard: closeme 2009-12-20
Created attachment 444384 [details]
reply window empty

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

Comment 10

8 years ago
Yes, exactly!
Created attachment 451383 [details]
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
Don't know what the RFC says about the fact that the charset isn't set.

Comment 13

7 years ago
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

7 years ago
> (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.
Summary: Unable to forward messages → Unable to forward messages with empty charset
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

7 years ago
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.
Summary: Unable to forward messages with empty charset → Unable to forward messages (charset="")
(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)?
Gregory what are your settings wrt to sending emails ?

Comment 19

7 years ago
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

7 years ago
TB has to recode the message body for forwarding inline, that's probably where it breaks somehow (different algorithm than rendering for display).
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?
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.
Whiteboard: [closeme 2012-03-25]
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.