Closed
Bug 120728
Opened 23 years ago
Closed 22 years ago
forward as inline mishandles part of Japanese text body
Categories
(MailNews Core :: Composition, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.3alpha
People
(Reporter: momoi, Assigned: nhottanscp)
References
Details
(Keywords: intl, regression, Whiteboard: [adt1])
Attachments
(5 files, 1 obsolete file)
4.29 KB,
application/x-zip-compressed
|
Details | |
129.19 KB,
image/jpeg
|
Details | |
165.41 KB,
image/jpeg
|
Details | |
697 bytes,
patch
|
bugzilla
:
review+
sspitzer
:
superreview+
jesup
:
approval+
|
Details | Diff | Splinter Review |
3.32 KB,
patch
|
bugzilla
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
** 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•23 years ago
|
||
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•23 years ago
|
||
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.
Reporter | ||
Comment 3•23 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•23 years ago
|
||
Does this still happen?
Assignee | ||
Comment 5•23 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•23 years ago
|
||
Assignee | ||
Comment 7•23 years ago
|
||
*** Bug 134762 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 8•23 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•23 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•23 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•23 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
Whiteboard: [adt1]
Assignee | ||
Comment 12•23 years ago
|
||
Updated•23 years ago
|
Attachment #80104 -
Flags: review+
Comment 13•23 years ago
|
||
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•23 years ago
|
Target Milestone: --- → mozilla1.0
Comment 14•23 years ago
|
||
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•23 years ago
|
||
checked in to the trunk, asked branch check in approval
Comment 17•23 years ago
|
||
It's fixed on 04/23 trunk build. The problem described in bug 134762 is also fixed.
Assignee | ||
Comment 18•23 years ago
|
||
fixed in the trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 19•23 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 21•23 years ago
|
||
adding adt1.0.0+. Please check this into the branch as soon as possible and add the fixed1.0.0 keyword.
Assignee | ||
Updated•23 years ago
|
Whiteboard: [adt1] → [adt1] waiting for 'a='
Comment 22•23 years ago
|
||
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•23 years ago
|
||
fixed1.0.0, checked in to the branch
Keywords: fixed1.0.0
Whiteboard: [adt1] waiting for 'a=' → [adt1]
Comment 24•23 years ago
|
||
Verified as fixed on 4/29 branch build.
Keywords: fixed1.0.0 → verified1.0.0
Comment 25•22 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•22 years ago
|
||
I can reproduce this using 10/21 trunk.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.3alpha
Comment 27•22 years ago
|
||
Just fyi, it doesn't happen on the latest 1.0 branch build.
QA Contact: ji → jeesun
Assignee | ||
Comment 28•22 years ago
|
||
This seems to be HTML mail only.
Assignee | ||
Comment 29•22 years ago
|
||
It started from 6/19 (build ID 2002061908).
Assignee | ||
Comment 30•22 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•22 years ago
|
||
This is a historical code. Need to cover testing for bug 66098, bug 117956 also.
Assignee | ||
Comment 32•22 years ago
|
||
Attachment #106111 -
Attachment is obsolete: true
Comment 33•22 years ago
|
||
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•22 years ago
|
Attachment #106113 -
Flags: superreview?(bienvenu)
Comment 34•22 years ago
|
||
Comment on attachment 106113 [details] [diff] [review] fixed memory leak sr=bienvenu
Attachment #106113 -
Flags: superreview?(bienvenu) → superreview+
Assignee | ||
Comment 35•22 years ago
|
||
checked in to the trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•