287675 - 'Forward' causes character-encoding problem; 'Reply' does not.

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Michael Graubart]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050324
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050324

With the e-mail that I shall attach (as HTML) to this report, clicking on
'Forward' results in wrong character-encoding (a dash or quote is replaced by an
upper-case A in a square box), and the list of encodings in 'Options' has no
effect. If, on the other hand, 'Reply' is clicked, the character-encoding
remains OK — which permits a work-around (by changing the addressee after
clicking 'Reply').

Reproducible: Didn't try

Steps to Reproduce:
1.Open the e-mail.
2.Click on 'Forward'.
3.Examine the text of the original e-mail.
4.Repeat, clicking 'Reply' instead of 'Forward'.

Actual Results:  
Under 3, every dash and quotation mark is replaced by an upper-case A in a
square box.

Under 4, dashes and quotes remain dashes and quotes.

Expected Results:  
Under 3, just as under 4, dashes and quotes should remain dashes and quotes.

eMac G4, OS 10.3.8. Classic theme.

Comment 1

[Michael Graubart]

Attachment: E-mail saved as HTML file

Comment 2

[Michael Graubart]

Attachment: E-mail saved as HTML file

A second e-mail that displays the same bug.

Comment 3

[Michael Graubart]

I have made a further discovery. This was made using the original of the second
of the messages that I saved and attached to my bug report; I seem to have lost
the original of the first, so cannot try it with that.

1. I opened the e-mail and looked under 'Character encoding' in 'View'.
'Unicode' had been automatically checked.

2. I clicked 'Forward'. As before, the character encoding (notably that of the
Hebrew characters) was garbled.

2a. I looked at 'Character encoding ' under 'Options'. 'Unicode' was checked.
Checking anything else at this stage did not affect the look of the
to-be-forwarded e-mail.

3. I went back to the original e-mail and opened 'Character encoding'. Instead
of just noting that 'Unicode' had already been checked, I manually clicked
'Unicode'— so to speak, confirming Unicode as the chosen encoding.

4. I clicked 'Forward' again. This time, the text was correctly encoded.

It would seem that (unlike under 'Reply'), under 'Forward' the character
encoding of the original message is not carried over into the to-be-forwarded
version.

Comment 4

[David :Bienvenu]

dup?

Comment 5

[Jungshik Shin]

Possibly a dupe. Let me take it for now

Comment 6

[Jungshik Shin]

Michael, can you save one of 'problematic' emails using 'File | Save As | File'
and attach it here? I need to see the original email as it is (not converted to
html)

Comment 7

[Michael Graubart]

Attachment: E-mail with Hebrew characters, saved as 'File'.

Comment 8

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Michael Graubart]

This bug still appears in the case of e-mails from the particular source
originally cited.

Comment 10

[Mike Cowperthwaite]

Whether using Mozilla 1.7.12 or Seamonkey 1.0b-1219 (I know, out of date), 
I can't reproduce this problem (on Windows 2000) using the message in 
attachment 181743 [details].  Similarly, I can't reproduce using Thunderbird 1.5.  
This is true whether I view the message as plain or HTML, and whether I 
compose in plain or HTML.

(I do have a problem with the display of the original message as HTML: I'm 
only seeing the Hebrew characters, the Arabic ones are replaced by "unknown character" glyphs.  Strange, because the Arial font, specified in the HTML,
does have Arabic characters defined.  Viewing as plain text, Hebrew and 
Arabic are displayed as expected -- font is Lucida Console.)

I note that the message has been encoded for mail-transmission as quoted-printable; there are numerous bugs about forwarding a quoted-printable message, most recently bug 307023, which has a fairly extensive comment troubleshooting that bug's particular problem.

Comment 11

[alan premselaar]

for what it's worth, I see this problem with Japanese email in version 1.5.0.5 on mac OS X 10.4.7 (PPC)

this happens with plain text email as well as HTML (although I don't often use HTML mail)

for instance, if I receive an email from the US in us-ascii encoding, and then i select forward, type in japanese text and click send, the resulting sent email is improperly encoded.

it apparently ignores my default encoding settings of ISO-2022-JP and the encoding problem isn't apparent until after sending (when it's too late to fix).  i.e. there's no problem with the actual input of japanese characters, just once i click send it all gets converted to question marks.

this is highly reproducable as it happens consistently every time.

Comment 12

[Mike Cowperthwaite]

(In reply to comment #11)
> it apparently ignores my default encoding settings of ISO-2022-JP and the
> encoding problem isn't apparent until after sending (when it's too late to
> fix).  

The first part of this sounds like bug 301291, but I don't think it's the same as this bug.  If I understand the original report correctly, the characters are seen garbled in the compose window, whereas your problem doesn't occur until sending.

The second part -- that the mismatch of what you've entered and the selected encoding isn't caught -- is unexpected: if there are characters in the message body that don't match the encoding, you should be prompted to Send In Unicode (or cancel the send in order to fix the message body).  Please, first, review bug 301291, and determine whether you have any fallback character sets defined (as described at that bug).  If you can't resolve the problem using that information, please open a new bug, and provide a sample message -- save it as a .EML file and attach it to the bug using the 'Create New Attachment' link on the bug page.


(In reply to comment #10)
> (I do have a problem with the display of the original message as HTML: I'm 
> only seeing the Hebrew characters, the Arabic ones are replaced by "unknown
> character" glyphs.  Strange, because the Arial font, specified in the HTML,
> does have Arabic characters defined.  [...] )

I'm not seeing this (unrelated) symptom with my current 2a1 build, but many things may have changed; I'm running on a different Win2K install at this point.  

But I just tried again to reproduce the original bug and still can't -- the inline-forward of attachment 181743 [details] looks correct to me, whether I forward as HTML or plain.  Perhaps it's a Mac-only bug?

I notice that in the compose window, the Character Encoding menu is checked as "Western (ISO-8859-1)" (my default) but when I send it it's automatically reset to UTF-8 (to follow the original message's encoding) which presumably it's supposed to (but again, viz. bug 301291).

Comment 13

[alan premselaar]

(In reply to comment #12)
> (In reply to comment #11)
> > it apparently ignores my default encoding settings of ISO-2022-JP and the
> > encoding problem isn't apparent until after sending (when it's too late to
> > fix).  
> 
> The first part of this sounds like bug 301291, but I don't think it's the same
> as this bug.  If I understand the original report correctly, the characters are
> seen garbled in the compose window, whereas your problem doesn't occur until
> sending.
> 

your right, it does sound more like 301291 (after reading it)

> The second part -- that the mismatch of what you've entered and the selected
> encoding isn't caught -- is unexpected: if there are characters in the message
> body that don't match the encoding, you should be prompted to Send In Unicode
> (or cancel the send in order to fix the message body).  Please, first, review
> bug 301291, and determine whether you have any fallback character sets defined
> (as described at that bug).  If you can't resolve the problem using that
> information, please open a new bug, and provide a sample message -- save it as
> a .EML file and attach it to the bug using the 'Create New Attachment' link on
> the bug page.
> 

After doing more testing to submit useful information, I've determined that this appears to be directly related to the Enigmail extension so I'll redirect this issue to them. (unless you feel it's appropriate to open a new bug ticket here)

sorry for the noise.

Comment 14

[Michael Graubart]

I am afraid I have had no e-mails of the kind that was the subject of my report, i.e. with a headline text in Hebrew characters, from this source for a long time and therefore cannot test this bug.

Comment 15

[lenochod]

 (In reply to comment #14)
> I am afraid I have had no e-mails of the kind that was the subject of my
> report, i.e. with a headline text in Hebrew characters, from this source for a
> long time and therefore cannot test this bug.

I close this for now as wontfix.
If anybody still run into this problem while using an recent Build,
please reopen and submit actual information.

Comment 16

[[e-mail]]

I have just faced the same issue in my recent thunderbird plus BIDI addon
I just have changed my default mail encoding to simply UTF-8 ,and it seems working.
Although before this change the issue was not persistant and was showing just some times.