Unable to process Non-MIME 8-bit headers properly

VERIFIED FIXED in M8

Status

MailNews Core
MIME
P3
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Katsuhiko Momoi, Assigned: nhottanscp)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
** Observed with 4/28/99 Win32 build **

For the thread pane Subject display, we are now decoding and
displaying MIME-encoded 8-bit and CJK headers. But sometimes
the Subject may contain raw 8-bit characters.
For these cases, I either see XML parser errors or
weird character substitutions (e.g. A Korean character for a
French 8-bit character.)

I understand that these are not going to be handled until M6.
This bug is filed then as a reminder to check on this type of
headers.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M6
(Assignee)

Comment 1

18 years ago
Accepting bug, set to M6.

Updated

18 years ago
QA Contact: 4080 → 1308
(Assignee)

Comment 2

18 years ago
Adding rhp@netscape.com to cc.
This is going be controlled by the charset menu. See the related bug 5938.
(Assignee)

Comment 3

18 years ago
I realize that the thread pane subject view is a separate issue that I am doing
with Rich. I'll take a look and see what we should change.
(Assignee)

Comment 4

18 years ago
This is related to the folder charset (set through charset menu UI), #3966.
(Assignee)

Updated

18 years ago
Target Milestone: M6 → M7
(Assignee)

Comment 5

18 years ago
Moving to M7, MIME decoder needs to get mail folder charset (see #3966).
Regarding the original report, there are two parts. The thread pane display is
the one which is going to be fixed in M7. The second problem of XML parser error
is a part of #5938.
By the way, I can see Latin1 Non-MIME 8-bit headers (prorbably Latin1
converter is used as the default). But I think that's only for Latin1.
(Assignee)

Updated

18 years ago
Depends on: 3966
(Assignee)

Comment 6

18 years ago
Just for my memo, I should enable the code for this bug.

Index: mailnews/mime/src/comi18n.h
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/comi18n.h,v
retrieving revision 1.11
diff -c -r1.11 comi18n.h
*** comi18n.h	1999/06/03 01:08:23	1.11
--- comi18n.h	1999/06/11 00:57:56
***************
*** 39,45 ****
   *
   *
   * @param header      [IN] A header to decode.
!  * @param charset     [OUT] Charset name (in C string) from a MIME header is
set.
   *                    Caller should allocate at least 65 bytes (kMAX_CSNAME +
1) for a charset name.
   * @return            Decoded buffer (in C string) or return NULL if the
header is not MIME encoded.
   */
--- 39,46 ----
   *
   *
   * @param header      [IN] A header to decode.
!  * @param charset     [IN/OUT] Input default charset or empty string to be
used for non MIME labeled header,
!  *                    After the decode charset name (in C string) from a MIME
header is set.
   *                    Caller should allocate at least 65 bytes (kMAX_CSNAME +
1) for a charset name.
   * @return            Decoded buffer (in C string) or return NULL if the
header is not MIME encoded.
   */
Index: mailnews/mime/src/comi18n.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/comi18n.cpp,v
retrieving revision 1.28
diff -c -r1.28 comi18n.cpp
*** comi18n.cpp	1999/06/03 03:12:07	1.28
--- comi18n.cpp	1999/06/11 00:57:56
***************
*** 1729,1735 ****
--- 1729,1742 ----
    // No MIME encoded, duplicate the input and put us-ascii as a charset
    if (*header == '\0' || !intlmime_is_mime_part2_header(header)) {
      result = PL_strdup(header);
+ #if 1
      PL_strcpy(charset, "us-ascii");
+ #else
+     // Put us-ascii as a charset if the default charset is not specified.
+    if (*charset == '\0') {
+       PL_strcpy(charset, "us-ascii");
+    }
+ #endif
    }
    else {
      char *header_copy = PL_strdup(header);  // avoid to modify the original
string
(Assignee)

Updated

18 years ago
Target Milestone: M7 → M8
(Assignee)

Comment 7

18 years ago
3966 got fixed last night, I updated the tree and apply my changes but the
testing failed. I think I have one more place to change (nsMimeConverter.cpp).
Regarding the fix of 3966, I saw the folder charset is passed down to MIME
decoder so I can say that it's fixed. But for this bug, I need more time to
change the code and to test. Currently, all Non MIME 8 bit headers are
interpreted as Latin1 (so we can see Latin1 Non MIME and Non MIME Japanese is
very rare).
Moving target to M8.
(Assignee)

Updated

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

Comment 8

18 years ago
Fix checed in mime/src/comi18n.cpp rev=1.30, mime/src/nsMimeConverter.cpp
rev=1.6.
Note for verification:
Charset menu change does not cause reload thread pane (8206). To see the change,
click other folder then click back.
Because Latin1 has been working, something other charset should also be tested.
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 9

18 years ago
** Checked with 6/25/99 Win32 M8 build **

I looked at some Latin msg headers which contain 8-bit characters without MIME-encoding.
They all failed to display correctly in the message viewing window thougg they displayed OK
in the thread pane. I tried switching to some other folder and come back to the msgs I wanted to
display but this did not work, either.  Maybe it's not easy to reset the folder encoding?

The error message was something like: "XML Error in file 'file://c:/temp/tempMessage.eml?header=only', Line Number: 5,
Col Number: 739, Description: mismatched tag"


I'm re-opening this bug for now ...
(Reporter)

Updated

18 years ago
Resolution: FIXED → ---
(Reporter)

Comment 10

18 years ago
Correction:

I was looking at only Latin 1 examples. That's not going to really
reveal the fix. So I tried Latin 2 non-MIME headers.
By changing the encoding to Latin 2 and higlighting another
folder and then back, I was able to display Latin 2 characters
OK which were not displayed correctly initially in the thread pane.

However, the message viewing window's subject header displays
incorrectly. Unlike the case of Latin 1 headers, I didn't get
XML parser error but still it displays incorrectly.

My initial bug report was about not being able to deal with non-MIME
8-bit headers correctly, and it implicitly referred to both thread pane and
message window problems -- note my mention of XML parser error
in such cases which you get in the message viewing window.

So, even though the thread pane display now correctly reflects
the folder charset as in this Latin 2 message, the viewing window
problem needs to be resolved.
(Assignee)

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

18 years ago
Message view pane problem has been filed separately (5938 - charset override).
That bug should apply for both header and body. Can we mark this FIXED and add
comments to 5938?
(Reporter)

Updated

18 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 12

18 years ago
Thanks fo reminding me of that bug.
Let me now mark the fix here verified.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.