The default bug view has changed. See this FAQ.

[Beta] MIME-encoded JPN address-from characters are not displayed correctly in thread pane

VERIFIED FIXED in M14

Status

MailNews Core
Backend
P3
critical
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Katsuhiko Momoi, Assigned: scottputterman)

Tracking

Trunk
x86
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
** Observed with 6/17/99 Win32 build **

I have a msg in which the address-to field contains MIME-encoded
Japanese characters along with the offical e-mail address. The
line looks like this un-decoded:

From: =?iso-2022-jp?B?GyRCRW0wZj4hSScbKEI=?= <momoi@netscape.com>

This should be decoced and displayed correctly but it is not in the
thread pane. Instead it shows as 4 dots, which seem to corresond
to the number of Japanese characters. Naoki had a case where his
3 Japanese characters show as 3 dots.

This header does show correctly in the message viewing window's header.

Scott, I can send you a sample message in which the addree-to header,
subject header, and the identical strings. (Just le me know your test
address). With a Japanese font somewhere in your system, you should
be able to see the difference between thread and message viewing pane.
(Reporter)

Updated

18 years ago
QA Contact: lchiang → momoi
(Reporter)

Comment 1

18 years ago
Assigned myself as teh QA contact.

Comment 2

18 years ago
Adding scottip to the cc list as well.

When I fetch new mail from a pop server, I'm not decoding the header info before
inserting it into the database. I wonder if the decoding of the From header
needs to happen here (we could convert it to the character set of the folder we
are adding the msg to) OR if the header needs to be decoded when we go to
display it in the thread pane (which would be a scottip area).
(Reporter)

Updated

18 years ago
Summary: MIME-encoded JPN address-to characters are not displayed correctly in thread pane → MIME-encoded JPN address-from characters are not displayed correctly in thread pane
(Reporter)

Comment 3

18 years ago
I'm sorry my example was for "address-from" field, not "address-to" filed.
Scott, do you want me to try the address-to field with some JPN
characters. (I corrected the summary above).
(Reporter)

Comment 4

18 years ago
I tried including JPN in the adress-to field.
These characters showed OK in the message viewing headers.
The address-to is not used in the thread pane and so this does
not seem to be an issue.

Comment 5

18 years ago
Additional info, I have a case of ISO-8859-1 and that displays correctly. If
MIME decode were missing, that should have failed too.

From: =?iso-8859-1?Q?Sant=E9?=  Nouveau!

Comment 6

18 years ago
I need to look at triaging this bug and giving it a target milestone fix. naoki,
your last set of comments confused me. It made me think that things are working?
I think I've just lost track of what needed fix. Or are we doing some decoding
as being evidenced by your discovery on 6/17 just not all the necessary
decoding?

Is the encoding problem in the thread pane or in the message pane for the
address-from line?

thanks!

Comment 7

18 years ago
What I meant was that this might not be the case where MIME decode is missing.
In order to show headers correctly, we need to MIME decode and convert to
unicode. As far as I've seen MIME deocode is done because I don't see raw MIME
encoded strings like below. But charset conversion may be missing because I
cannot see the fist example below but I can see the second one (Latin1
range usually works without charset conversion).
From: =?ISO-2022-JP?B?GyRCSlQ9ODZJGyhC?= <cnet@sphere.ad.jp>
From: =?iso-8859-1?Q?Sant=E9?=  Nouveau!

Updated

18 years ago
Blocks: 7228

Updated

18 years ago
Target Milestone: M9 → M11

Comment 8

18 years ago
changing TFV to M11.

Comment 9

18 years ago
I thought this was more a scottip issue, because we're storing the header
undercoded, as planned, and only doing the decoding before display. Scott, isn't
this right? It looks like we're doing the GetMime2DecodedAuthor, which seems
like what we're supposed to do. Or is it the charset conversion we're missing?
(Assignee)

Comment 10

18 years ago
I'm not doing anything with charsets.
(Reporter)

Comment 11

18 years ago
What's going on with this bug? It is marked for M11 and
we haven't seen any noise on it for a month now.
Scott, please update.

Comment 12

18 years ago
I haven't started to look at it. I'd say it's on the bubble for me getting to it
for m11.

Comment 13

18 years ago
(I should add that Phil is helping me priortize my M11 bugs and I believe he's
going to be making a pass through all our bugs Monday).

I was just scanning through this bug report and I'm still slightly confused by
Naoki's last comments. He makes it sound like MIME decode is happening (which
would be my end of the boat) but the problem may be in some character set
conversion stuff ?? (would that be scottip?)

Updated

18 years ago
Blocks: 14356

Updated

18 years ago
Blocks: 11091

Comment 14

18 years ago
(target milestone is M11 or M12 - add to mail beta tracking bug)

Comment 15

18 years ago
Created attachment 1793 [details]
screen shot and its inbox data

Comment 16

18 years ago
I debugged this and found that nsAutoCString(sender) is used in the code. That
only works for Latin1 characters.
In order to work correctly, it needs unicode conversions. Since it's converting
between UCS2 and UTF-8, there is a easier way.
My code below leaks, so do not paste this, this is just an idea how to convert.


#include "nsTextFormater.h"
//sender is the string we need to parse.  senderuserName is the parsed user name
we get back.
nsresult nsMsgMessageDataSource::GetSenderName(nsAutoString& sender,
nsAutoString *senderUserName)
{
	//XXXOnce we get the csid, use Intl version
	nsresult rv = NS_OK;
	if(mHeaderParser)
	{
		char *name;
#if 0
		if(NS_SUCCEEDED(rv = mHeaderParser->ExtractHeaderAddressName
(nsnull, nsAutoCString(sender), &name)))
		{
			*senderUserName = name;
		}
#else
		if(NS_SUCCEEDED(rv = mHeaderParser->ExtractHeaderAddressName
("UTF-8", sender.ToNewUTF8String(), &name)))
		{
      PRUnichar *u;
      nsAutoString fmt("%s");
			u = nsTextFormater::smprintf(fmt.GetUnicode(),name);
      senderUserName->SetString(u);
		}
#endif
(Assignee)

Updated

18 years ago
Assignee: mscott → putterman
Status: ASSIGNED → NEW
Target Milestone: M11 → M12
(Assignee)

Comment 17

18 years ago
reassigning to me.
(Reporter)

Updated

18 years ago
Severity: normal → critical
(Reporter)

Comment 18

18 years ago
Im raising the severity of this bug. Being able to see the
sender's name correctly in the thread pane seems to be a
basic functionality we expect in mail. Also evaluating this
for Dogfood.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: M12 → M14
(Reporter)

Updated

18 years ago
Summary: MIME-encoded JPN address-from characters are not displayed correctly in thread pane → [Beta] MIME-encoded JPN address-from characters are not displayed correctly in thread pane
(Reporter)

Comment 19

18 years ago
We need to get this into Beta 1. I can't think of pushing Beta without
this working OK. Mail looks terrible when you cannot see the sender's
names in CJK languages.
Bob, please add this to the Beta 1 list.

Updated

17 years ago
Keywords: beta1
(Reporter)

Comment 20

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

Comment 21

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

Comment 22

17 years ago
*** Bug 25176 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Comment 24

17 years ago
fix checked in.  The message the momoi sent me showed up with the correct sender 
in the thread pane on all 3 platforms.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Updated

17 years ago
Blocks: 25176
(Reporter)

Comment 25

17 years ago
** Checked with 2/3/2000 Win32 build **

Looks great. I have been able to confirm so far that properly MIME-encoded
Sender names in Latin 1, Russian (KOI8-R-), Japanese (ISO-2022-JP), and
Trad Chinese (Big5) dispay correctly in the thread pane.

ji, can you confirm that this is OK on Linux.
I'm going to mark this verified/fixed. Please re-open if there is a problem on Linux.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.