66098 - Non MIME header support for Forward

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P4)

Description

[Tomoo Nomura]

In case that the header of received message contains 8 bit characters and it is
not mime encoded, mozilla can display the header correctly.
However, replying to the message, the subject field and receipient field in the
new message can not be displayed correctly. These fields can't
 handle so called 8 bit through header. NS 4.x and IE5.x can do t

Comment 1

[Katsuhiko Momoi]

This is probably a duplicate of Bug 41009.

Comment 2

[nhottanscp]

If reproducible, this should be a dup of bug 39736.
IQA please test and reopen bug 39736 and mark this as a dup.

Comment 3

[ji]

Reopened bug 39736.
Marked this one as a dup of 39736.

*** This bug has been marked as a duplicate of 39736 ***

Comment 4

[Katsuhiko Momoi]

As I mentioned in the other bug.
This is not a duplicate of Bug 39736
which is about body quoting. This bug is
about header quoting.

See my comments in Bug 41009 at:

Additional Comments From Katsuhiko Momoi 2000-08-10 17:26 

If this is not strictly a duplicate of Bug 41009,
then this bug should be kept open.

Comment 5

[ji]

Hi Naoki, the problem described in bug 41009 is about the failure of "Edit as 
New" funtion for msgs w/o MIME headers. And this one is about reply/forward.  
Are they calling the same module?  If they do, we have three bugs: this one, 
41009, 39736, to point to the same problem, although we need to modify the 
summary of bug 41009 to better reflect the problem. 

Comment 6

[nhottanscp]

I am not sure if they use the same code. 
Looks like this bug is about headers not body so let's reopen this and keep as
separate.

Comment 7

[nhottanscp]

Attachment: Patch, for reply, need a separate patch for forward

Comment 8

[nhottanscp]

Attachment: Patch, for forward inline, changed to pass default charset, removed unnecessary conversion

Comment 9

[Jean-Francois Ducarroz]

just one thing: in nsMsgCompose.cpp, line 966, can you remove the comment that say that encodedCharset is not 

used. Appart that, R=ducarroz

Comment 10

[nhottanscp]

Okay, I will change it before check in.

Comment 11

[David :Bienvenu]

sr=bienvenu

Comment 12

[nhottanscp]

checked in

Comment 13

[Tomoo Nomura]

I checked on Build 20010219. The recipient field seems to have been fixed, but
cc: field still has the problem, when choosing "reply all".

Comment 14

[ji]

Tomoo, could you attach a testcase to the report? thanks.

Comment 15

[Tomoo Nomura]

Attachment: unzip, move to mail folder, launch Mozilla, choose "check" folder, choose the message and "reply all"

Comment 16

[ji]

Confirmed the problem. Reopened the bug.

Comment 17

[nhottanscp]

Reopen, I only fixed for subject header.

Comment 18

[nhottanscp]

*** Bug 73985 has been marked as a duplicate of this bug. ***

Comment 19

[nhottanscp]

Need forward as attachment change, should wait for the MIME decoder change bug 
65277.

Comment 20

[Jaime Rodriguez, Jr.]

adding nsbeta1 keyword, and jenm to cc: list.

Comment 21

[nhottanscp]

Attachment: Patch, separated a code to get a top most window's charset as a function, so it can be called by both reply and forward.

Comment 22

[Jean-Francois Ducarroz]

R=ducarroz

Comment 23

[David :Bienvenu]

yuck - well, sr=bienvenu

Comment 24

[nhottanscp]

*** Bug 80830 has been marked as a duplicate of this bug. ***

Comment 25

[nhottanscp]

checked in for forward attachment.

Future the remaining problems, non subject header support Non MIME headers.

Comment 26

[Tomoo Nomura]

This problem in subject and sender field seemed to be fixed once at the
beginning of May, but it has reappeared while reply, forward and attachment
field's problems have been fixed. I checked on Build 20010525 20010527 20010531
20010604 and 2001060908.

Comment 27

[ji]

Nominating for nsbeta1, this problem still exists on 01/17 build.
Forward-inline for non-MIME encoded mail headers doesn't inherit the specified
folder charset. But it can inherit the charset that the user specified from
charset menu.
Reply doesn't have this problem for headers. Modified the summary accordingly.

Comment 28

[ji]

Please note that forward inline once got fixed in 6.2, but now it's broken.

Steps to reproduce:
1. Select a non-MIME encoded iso-2022-jp mail.
2. Set the proper folder charset to correct the view.
3. Click on Forward button, observe the corruption in subject. 
4. Select the iso-2022-jp charset from charset menu, click on Forward button,
you can see in this case forward inline can take the right charset specified
from menu.

Comment 29

[nhottanscp]

I think this is similar to bug 115869. I think this is related to my fix for
file name support (supporting filename charset different from the mail body's
charset).

Comment 30

[nhottanscp]

nsbeta1+ per i18n triage

Comment 31

[nhottanscp]

This problem is different from the reply/quote (bug 118740).
For forward inline, it always fails to get a folder charset. This used to be a
non problem since we always set a override flag (so folder charset was not used).

Comment 32

[nhottanscp]

*** Bug 122465 has been marked as a duplicate of this bug. ***

Comment 33

[Denis Antrushin]

> I think this is similar to bug 115869.

In some sense :-) 
The problem in bug 115869 is reverse on this one - In this bug
we don't check folder encoding, while in 115869 we check only folder encoding
and not msg window override charset

Comment 34

[Denis Antrushin]

This bug consitts of two parts: first, we don't use default charset when
msg charset empty and there is no msg window charset override (mimedrft.cpp);

Second, we always failing to get folder charset when sending 
draft/template/fwd inline.
Looks like problems with CreateStartupUrl()
Problem in using two notations to reference message number in urls: ?number=<num>
and #<num>. nsMailboxUrl.ParseUrl expects msg number in form ?number=, but
sometimes gets it as #. This part is will be fixed by patch for bug 110689
(despite it says it's just code cleanup)

Comment 35

[Denis Antrushin]

Attachment: Patch, use default charset, if there no charset specified

Fix for first problem...

Comment 36

[nhottanscp]

Thanks for finding the problem. The problem is fixed after I applied the patch
in this bug and the one in bug 110689).

About the patch, since the next line after your patch checks for mdd->options,
you can include your change inside that if clause.

Comment 37

[Denis Antrushin]

Attachment: v2 of the above patch

I also check charset_override now. Naoki, does it seems reasonable?

Comment 38

[nhottanscp]

Comment on attachment 67414 [details] [diff] [review]
v2 of the above patch

r=nhotta

Comment 39

[nhottanscp]

The comment,
-      // mscott: aren't we leaking a bunch of trings here like the charset
strings and such?

I think that is true, so please don't remove.

Comment 40

[David :Bienvenu]

You can just use PR_Free instead of PR_FREEIF, because PR_Free will check for
null, and you don't need the assigning to null behaviour of PR_FREEIF because
you're assigning it in the next statement.

Comment 41

[Denis Antrushin]

Naoki, what we're leaking here?
members of MimeDisplayOptions which may leak are:
mozITXTToHTMLConv   *conv      - not used in mimedrft.cpp at all
nsIPref             *pref      - freed in mime_stream_complete
char        *part_to_load      - freed in ~MimeDisplayOptions
char     *default_charset      - ditto

What else we may be leaking?

Comment 42

[Denis Antrushin]

Attachment: patch v2.01; replaced PR_FREEIF with PR_Free

Comment 43

[nhottanscp]

>What else we may be leaking?

How about MimeDisplayOptions::url?

Comment 44

[nhottanscp]

Comment on attachment 68862 [details] [diff] [review]
patch v2.01; replaced PR_FREEIF with PR_Free

r=nhotta

Comment 45

[nhottanscp]

David, could you review the latest patch?

Comment 46

[David :Bienvenu]

Comment on attachment 67414 [details] [diff] [review]
v2 of the above patch

sr=bienvenu

Comment 47

[nhottanscp]

checked in the patch but need bug 110689 to get the folder charset

Comment 48

[nhottanscp]

depends on bug 110689

Comment 49

[Denis Antrushin]

Attachment: folder charset part

Here is rest of needed changes to fix this.

(no more depend on 110689)

Comment 50

[nhottanscp]

Comment on attachment 72391 [details] [diff] [review]
folder charset part 

r=nhotta

This is for forward inline. By the change, PrepareMessageUrl is called and that
makes a folder charset to be retrieved correctly later, and the reply quote
code also uses GetUrlForUri instead of CreateStartupUrl.
I cc to ducarroz in case he wants to review it.

Comment 51

[(not reading, please use [e-mail] instead)]

Comment on attachment 72391 [details] [diff] [review]
folder charset part 

sr=sspitzer

please test forwarding for imap, news and local.

Comment 52

[ji]

Naoki, does this patch take care of CC and BCC fields? If not, I'd like to open
a seperate bug.

Comment 53

[nhottanscp]

You mean 'cc' in the quoted text in the body for forward inline?

Comment 54

[nhottanscp]

Attachment: Updated for the recent URI change (SetSpec argument type change).

Comment 55

[ji]

yes, the cc part in the quoted text in the body for forward inline

How about Edit as new and edit draft? Does this patch take case of those cases too?

Comment 56

[ji]

Attachment: Another testcase: a Ja SJIS mail with non-MIME encoded CC and BCC field.

Comment 57

[ji]

Attachment: One more case: a Ja sjis mail with non-MIME encoded To/Cc/Bcc/Reply-to/Organization header.

Comment 58

[nhottanscp]

Comment on attachment 72815 [details] [diff] [review]
Updated for the recent URI change (SetSpec argument type change).

r=nhotta

Comment 59

[nhottanscp]

With the patch, the last two test cases quoted fine if I set the folder charset
to Shift_JIS. Not all the headers are quoted (e.g. bcc is not quoted), I think
that is by design.

Comment 60

[ji]

Per discussion with Naoki, filed bug 129349 for the display problem with the
non-MIME encoded Reply-To and Bcc header when editing message as new.

Comment 61

[(not reading, please use [e-mail] instead)]

Comment on attachment 72815 [details] [diff] [review]
Updated for the recent URI change (SetSpec argument type change).

sr=sspitzer

Comment 62

[Asa Dotzler [:asa]]

Comment on attachment 72815 [details] [diff] [review]
Updated for the recent URI change (SetSpec argument type change).

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 63

[石庭豐 (Seak, Teng-Fong)]

There seems to be at least one more issue (cf bug 129256 & bug 129349) not yet
under consideration: BCC header isn't MIME-encoded by Mozilla (as shown when we
save a message and "Edit Draft" again).  Maybe another bug has to be filed?

Comment 64

[石庭豐 (Seak, Teng-Fong)]

Oh, by the way, is there a bug already filed about Mozilla crashed by forwarded
mails?  I don't know how to reproduce the exact situation.  I think I'd better
make a test case for that if you think a new bug is needed.

nhotta: why is BCC unquoted by design?

Comment 65

[Denis Antrushin]

Reply-To and BCC problems is bug #64092
(mozilla1.2, nsbeta-, patch, review).

Comment 66

[nhottanscp]

>nhotta: why is BCC unquoted by design?

I was wrong, you can change it to show all headers by View->Headers.

Comment 67

[nhottanscp]

checked in to the trunk

Thanks for the contribution.

Comment 68

[ji]

Verified as fixed with 03/20 builds.

Comment 69

[Tomoo Nomura]

This problem has occured again since 2002032203 to 2002033109.

The problem occures when the mail has the header of
Content-Type: text/plain; charaset="iso-2022-jp" . 

When forwarding to this mail, Japanese characters can't display correctly.
In case of reply, there is no problem.

Tomoo

Comment 70

[ji]

Tomoo, I don't see this on 03/28 build. Did you see the corruption in subject or
body?

Comment 71

[Tomoo Nomura]

I saw the corruption in body.

Comment 72

[Tomoo Nomura]

Attachment: Test Data

unzip, move to mail folder, launch Mozilla, choose check3 folder, choose
message and forward.

Comment 73

[ji]

Tomoo, the mail you just attached is an ISO-2022-JP mail with MIME header,  and
it's also a reply mail with original one having no MIME header and it has added
some lines above the quoted mail.
It has two problems when doing forward on this mail:
1. The added lines is garbled
2. The quoted part in the mail is dropped when forwarding.

I think this is a different one with this bug since the mail you try to forward
has MIME header.
Could you file a seperate bug on this or do you want me to do it?
Please let me know. Thanks.

Comment 74

[Tomoo Nomura]

#134762 is a new entry.
Please follow it up.

Tomoo

Comment 75

[nhottanscp]

Attached test case,
http://bugzilla.mozilla.org/attachment.cgi?id=25725&action=view
"To:" has problem when forward as inline. Other test cases do not have that
problem. I guess it is releated to the non-MIME encoded multiple line header.
Xianglan, could you try that using NS 7 and file as a separate bug?

Comment 76

[ji]

Filed bug 180025 for above problem.