Non-ascii in plain text attachment body are garbled

VERIFIED FIXED in M11

Status

MailNews Core
Internationalization
P3
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: marina, Assigned: nhottanscp)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
When receiving a message with plain text attachment that contains non-ascii in
the body they are garbled.It looks right in 4.x and this is what we have in Page
source:
Content-Type: text/plain;
 name="plain.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="plain.txt"
I remember that : inline was causing problems before.
Steps to reproduce:
-open new mail;
-click Attach icon, attach a plain text file (see an exemple in the
attachments);
-send message to both 4.x and 5.0;
-open message in 4.x and 5.0;
//note: in 4.x mail body has a correct display of the 8-bit chars opposite to
the wrong display in 5.0
(Reporter)

Comment 1

19 years ago
Created attachment 2018 [details]
this is a plain text file a used
(Assignee)

Updated

19 years ago
Summary: Non-ascii in plain text attachment body are garbled → Non-ascii in plain text attachment body are garbled
(Assignee)

Comment 2

19 years ago
The problem starting with today's build?
How about the main body with 8 bit chars (4.x can send it by setting a pref)?

Comment 3

19 years ago
Could you check the charset for the first part?
If the first pasrt is US-ASCII, can we actually
view 8-bit Latin 1 data in the 2nd part of multupart?
Could this possibly be charset menu not working in
this case? --> known problem.

Comment 4

19 years ago
It turns out that 5.0 can display the same plain text file
when it is sent from 4.7. Note the structural difference:

--------------------- Sent from 4.7 --------------------

This is a multi-part message in MIME format.
--------------2FAA5FFF6A8E5638C8852496
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
T&eacute;l&eacute;chargez Netscape</html>

--------------2FAA5FFF6A8E5638C8852496
Content-Type: text/plain; charset=iso-8859-1;
 name="frhome.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="frhome.txt
----------------------------------------------------

Compare this to the one sent from 5.0 via polyglot as SMTP server:

--------------- Sent from 5.0 via polyglot --------------

This is a multi-part message in MIME format.
--------------040409010406090707090205
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------040409010406090707090205
Content-Type: text/plain;
 name="frhome.txt"
Content-Disposition: inline;
 filename="frhome.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id LAA23987

-------------------------------------------------------------

Note that nsmail-2 does not do QP-conversion but polyglot does.
In any case, 5.0 has difficulty displaying Latin 1 characters
in the latter (sent from 5.0) but not the former (sent from 4.7).

The only significant difference I see here is the lack of the charset
parameter in the latter.

Comment 5

19 years ago
My point is that whether or not the attachment
contains raw 8-bit does not seem to be the controlling
factor for this problem. 5.0 has the same problem with
the QP data when the multipart does not have a charset
parameter.

Is this then a duplicate of "charset menu not effective for the
body" bug?

Comment 6

19 years ago
BTW,

1. Main Body in 8 bit from 4.7 -- display OK in 5.0.
2. Won't be able to check if this is a regresion from M10
   because of Bug 15577 in M10.
(Reporter)

Comment 7

19 years ago
1.plain text body sent from 5.0 comes blank (bug#15313)
2.plain text settings in prefs.js are ignored (bug#15238), you still get an html
window
3.if your settings are html, true, your attachment will hang apprunner upon send
The conclusion of testing is:
-View is OK (Plain text sent from 4.x is displayed correctly);
-charset for the first part is us-ascii (but the text can not be seen because of
bug#15313);
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 8

19 years ago
If the attachment does not have charset label, the main body charset is used. We
do not label attachment charset unless it has a label (html META charset). So
the behavior described in this bug is an expected result.
The problem is resolved by the auto charset detection (e.g. Japanese) but it is
default to off and no detection for Latin1.
How about changing the fallback a little bit to use Latin1 if the attachment is
not labeled and the main body is us-ascii? Rich, what do you think?
(Assignee)

Updated

19 years ago
Target Milestone: M11
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 9

19 years ago
I checked in a fix yesterday. Using today's build (my locale), I can see a plain
text French text which had the problem before the fix.
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 10

19 years ago
in the today build 1999-10-18-09 M11 i can reproduce the problem so reopening
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
(Assignee)

Comment 11

19 years ago
If the charset detection is on the fall back I added is not used.
Verification should be done without charset detection.
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 12

19 years ago
without charset detection (auto-detect= off) it is working, so verifying as
fixed.

Updated

19 years ago
QA Contact: momoi → marina
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.