Closed Bug 66098 Opened 20 years ago Closed 19 years ago

Non MIME header support for Forward


(MailNews Core :: Internationalization, defect, P4)


(Not tracked)



(Reporter: nomura, Assigned: nhottanscp)



(Keywords: intl, regression)


(11 files, 1 obsolete file)

923 bytes, patch
Details | Diff | Splinter Review
4.77 KB, patch
Details | Diff | Splinter Review
2.07 KB, application/octet-stream
3.35 KB, patch
Details | Diff | Splinter Review
911 bytes, patch
Details | Diff | Splinter Review
1.03 KB, patch
: review+
: superreview+
Details | Diff | Splinter Review
1.03 KB, patch
: review+
Details | Diff | Splinter Review
743 bytes, patch
: review+
: superreview+
Details | Diff | Splinter Review
933 bytes, text/plain
1.01 KB, text/plain
1.75 KB, application/binary
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
This is probably a duplicate of Bug 41009.
Ever confirmed: true
If reproducible, this should be a dup of bug 39736.
IQA please test and reopen bug 39736 and mark this as a dup.

Keywords: intl
Reopened bug 39736.
Marked this one as a dup of 39736.

*** This bug has been marked as a duplicate of 39736 ***
Closed: 20 years ago
Resolution: --- → DUPLICATE
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.
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. 
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
Resolution: DUPLICATE → ---
Target Milestone: --- → mozilla0.9
just one thing: in nsMsgCompose.cpp, line 966, can you remove the comment that say that encodedCharset is not 

used. Appart that, R=ducarroz

Okay, I will change it before check in.
checked in
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
I checked on Build 20010219. The recipient field seems to have been fixed, but
cc: field still has the problem, when choosing "reply all".
Tomoo, could you attach a testcase to the report? thanks.
Confirmed the problem. Reopened the bug.
Resolution: FIXED → ---
Reopen, I only fixed for subject header.
OS: Windows 2000 → All
Priority: -- → P4
Hardware: PC → All
Target Milestone: mozilla0.9 → mozilla0.9.1
*** Bug 73985 has been marked as a duplicate of this bug. ***
Need forward as attachment change, should wait for the MIME decoder change bug 
Depends on: 65277
adding nsbeta1 keyword, and jenm to cc: list.
Keywords: nsbeta1
yuck - well, sr=bienvenu
*** Bug 80830 has been marked as a duplicate of this bug. ***
checked in for forward attachment.

Future the remaining problems, non subject header support Non MIME headers.
Target Milestone: mozilla0.9.1 → Future
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.
Summary: Can't produce 8 bit through header → Non MIME header support for Reply/Forward.
Blocks: 104166
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.
Keywords: nsbeta1
Summary: Non MIME header support for Reply/Forward. → Non MIME header support for Forward.
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.
Keywords: regression
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
Target Milestone: Future → mozilla0.9.9
nsbeta1+ per i18n triage
Keywords: nsbeta1nsbeta1+
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).
*** Bug 122465 has been marked as a duplicate of this bug. ***
> 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
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)
Depends on: 110689
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.

Blocks: 117956
No longer blocks: 117956
I also check charset_override now. Naoki, does it seems reasonable?
Comment on attachment 67414 [details] [diff] [review]
v2 of the above patch

Attachment #67414 - Flags: review+
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.
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.
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?
>What else we may be leaking?

How about MimeDisplayOptions::url?
Comment on attachment 68862 [details] [diff] [review]
patch v2.01; replaced PR_FREEIF with PR_Free

Attachment #68862 - Flags: review+
David, could you review the latest patch?
Comment on attachment 67414 [details] [diff] [review]
v2 of the above patch

Attachment #67414 - Flags: superreview+
checked in the patch but need bug 110689 to get the folder charset
depends on bug 110689
Target Milestone: mozilla0.9.9 → mozilla1.0
No longer depends on: 110689
Attached patch folder charset part (obsolete) — Splinter Review
Here is rest of needed changes to fix this.

(no more depend on 110689)
Comment on attachment 72391 [details] [diff] [review]
folder charset part 


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.
Attachment #72391 - Flags: review+
Comment on attachment 72391 [details] [diff] [review]
folder charset part 


please test forwarding for imap, news and local.
Attachment #72391 - Flags: superreview+
Naoki, does this patch take care of CC and BCC fields? If not, I'd like to open
a seperate bug.
Summary: Non MIME header support for Forward. → Non MIME header support for Forward
You mean 'cc' in the quoted text in the body for forward inline?
Attachment #72391 - Attachment is obsolete: true
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 on attachment 72815 [details] [diff] [review]
Updated for the recent URI change (SetSpec argument type change).

Attachment #72815 - Flags: review+
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.
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 on attachment 72815 [details] [diff] [review]
Updated for the recent URI change (SetSpec argument type change).

Attachment #72815 - Flags: superreview+
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
Attachment #72815 - Flags: approval+
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?
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?
Reply-To and BCC problems is bug #64092
(mozilla1.2, nsbeta-, patch, review).
>nhotta: why is BCC unquoted by design?

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

Thanks for the contribution.
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
Verified as fixed with 03/20 builds.
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, I don't see this on 03/28 build. Did you see the corruption in subject or
I saw the corruption in body.
Attached file Test Data
unzip, move to mail folder, launch Mozilla, choose check3 folder, choose
message and forward.
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.
#134762 is a new entry.
Please follow it up.

Attached test case,
"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?
Filed bug 180025 for above problem.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.