forward as inline mishandles part of Japanese text body

RESOLVED FIXED in mozilla1.3alpha

Status

MailNews Core
Composition
--
major
RESOLVED FIXED
17 years ago
10 years ago

People

(Reporter: Katsuhiko Momoi, Assigned: nhottanscp)

Tracking

({intl, regression})

Trunk
mozilla1.3alpha
x86
Windows 2000
intl, regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1])

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
** Observed with 2002-01-17 Win32 trunk build **

I hope there is a bug for this already. A look through known bugs
did not turn up the exact bug like this one.

1. I have a single part plain text msg in Japanese with Content-type
   charset of iso-2022-jp.
2. When I try to forward this message as inlie, some parts of 
    the body text get corrupted. I will attach an imgae of the problem
    and also will attach the test message below.
(Reporter)

Comment 1

17 years ago
Created attachment 65588 [details]
A .zip fiel containing the problem message. 

Un-archive the zip file and place the resulting mailbox file 
into a mail directory. Use it to make forward as inline function 
under plain text or HTML mail options.
(Reporter)

Comment 2

17 years ago
Created attachment 65589 [details]
A .jpg file showing a corruption problem.

It seems that where the text begins to get corrupted differs
whether or not the Compose option is set to HTML or plain text.
It also seems that where certain characters trigger this problem.

Updated

17 years ago
Keywords: intl
(Reporter)

Comment 3

17 years ago
Is there another bug that deals with this issue? 
If not, someone should look at this seriously. A lot
of users forward messages inline and not being able to do that 
would amount to disabling a basic functionality.
I would like a follow-up as soon as possible.
Keywords: nsbeta1
(Assignee)

Comment 4

17 years ago
Does this still happen?
(Assignee)

Comment 5

17 years ago
I tested with 4/18 commercial branch. Now it is broken for all the lines.
I will attach a screen shot.
Let me take a look at this.
Assignee: ducarroz → nhotta
(Assignee)

Comment 6

17 years ago
Created attachment 79923 [details]
Screen shot, result with 4/18 commercial branch.
(Assignee)

Comment 7

17 years ago
*** Bug 134762 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

17 years ago
According to bug 134762, 03/20 commercial build has the raw JIS display problem.
So far, I have not figured out what kind of message show this problem.
Status: NEW → ASSIGNED
(Assignee)

Comment 9

17 years ago
It looks like this is related to the JIS to Unicode converter behavior change
(bug 128580) which was checked in 3/20.
I think the actual problem is in the caller of the converter. Need more
investigation.
(Assignee)

Comment 10

17 years ago
I looked at this with Frank and found there is a problem in ISO-2022-JP
converter (bug 138578).
Frank thinks it is too risky to change the converter now, so I am going to try
workaround by the callers.
Depends on: 138578

Comment 11

17 years ago
this is regression from n6.2 and feb 2002 builds. 
This bug impact japanese only because we have a bug in the ISO-2022-JP converter. 
Impact users: Japanese users- 52.1M users 9.2% of total internet users.
chance to hit this bug: HIGH, almost every mail users will use forward as
inline. For all the japanese mail users use forward as inline, they will see
this problem 
This is [adt1] bug since it impact the major market in major function
Keywords: nsbeta1 → nsbeta1+, regression
Whiteboard: [adt1]
(Assignee)

Comment 12

17 years ago
Created attachment 80104 [details] [diff] [review]
Changed to use a different util function which does not call the converter repeatedly in a loop in order to workaround the converter problem.

Updated

17 years ago
Attachment #80104 - Flags: review+
Comment on attachment 80104 [details] [diff] [review]
Changed to use a different util function which does not call the converter repeatedly in a loop in order to workaround the converter problem.

R=ducarroz
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla1.0
Comment on attachment 80104 [details] [diff] [review]
Changed to use a different util function which does not call the converter repeatedly in a loop in order to workaround the converter problem.

sr=sspitzer
Attachment #80104 - Flags: superreview+
(Assignee)

Comment 15

17 years ago
checked in to the trunk, asked branch check in approval 

Comment 16

17 years ago
QA contact to myself.
QA Contact: sheelar → ji

Comment 17

17 years ago
It's fixed on 04/23 trunk build. The problem described in bug 134762 is also fixed. 
(Assignee)

Comment 18

17 years ago
fixed in the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 19

17 years ago
this patch fix a high visibility problem by using a different function to do the
same thing. This is a work around for a converter problem which are too risky to
change. please adt1.0.0+ it 

nhotta, please send mail to drivers@mozilla.org to ask driver to approve it also. 

QA already verify it on the trunk
>------- Additional Comment #17 From ji@netscape.com 2002-04-23 11:04 -------
>It's fixed on 04/23 trunk build. The problem described in bug 134762 >is also
fixed. 
Keywords: adt1.0.0

Comment 20

17 years ago
Verified as fixed with 04/23 trunk build.
Status: RESOLVED → VERIFIED

Comment 21

17 years ago
adding adt1.0.0+.  Please check this into the branch as soon as possible and add
the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
(Assignee)

Updated

17 years ago
Whiteboard: [adt1] → [adt1] waiting for 'a='
Comment on attachment 80104 [details] [diff] [review]
Changed to use a different util function which does not call the converter repeatedly in a loop in order to workaround the converter problem.

a=rjesup@wgate.com for branch checkin
Attachment #80104 - Flags: approval+
(Assignee)

Comment 23

17 years ago
fixed1.0.0, checked in to the branch
Keywords: fixed1.0.0
Whiteboard: [adt1] waiting for 'a=' → [adt1]

Comment 24

17 years ago
Verified as fixed on 4/29 branch build.
Keywords: fixed1.0.0 → verified1.0.0

Comment 25

16 years ago
It seems to reappear in the latest build, 2002100714.
I can't forward any Japanese messages.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 26

16 years ago
I can reproduce this using 10/21 trunk.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.3alpha

Comment 27

16 years ago
Just fyi, it doesn't happen on the latest 1.0 branch build.
QA Contact: ji → jeesun
(Assignee)

Comment 28

16 years ago
This seems to be HTML mail only.
(Assignee)

Comment 29

16 years ago
It started from 6/19 (build ID 2002061908).
(Assignee)

Comment 30

16 years ago
This is a regression by bug 146584.
There was a change in mimedrft.cpp to escape HTML body. Since ISO-2022-JP data
may contain '<', '>', we cannot apply escaping there. The escape may be applied
safely when the body data is in Unicode.
(Assignee)

Comment 31

16 years ago
Created attachment 106111 [details] [diff] [review]
Changed to do UTF-8 conversion right after we get the body.

This is a historical code.
Need to cover testing for bug 66098, bug 117956 also.
(Assignee)

Comment 32

16 years ago
Created attachment 106113 [details] [diff] [review]
fixed memory leak
Attachment #106111 - Attachment is obsolete: true
Comment on attachment 106113 [details] [diff] [review]
fixed memory leak

Can you use PR_Free(mimeCharset) instead of PR_FREEIF(mimeCharset). Except
that, R=ducarroz
Attachment #106113 - Flags: review+
(Assignee)

Updated

16 years ago
Attachment #106113 - Flags: superreview?(bienvenu)

Comment 34

16 years ago
Comment on attachment 106113 [details] [diff] [review]
fixed memory leak

sr=bienvenu
Attachment #106113 - Flags: superreview?(bienvenu) → superreview+
(Assignee)

Comment 35

16 years ago
checked in to the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 36

15 years ago
--> qa contact marina@netscape.com
QA Contact: jeesun → marina
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.