Closed
Bug 8405
Opened 25 years ago
Closed 25 years ago
[Beta] MIME-encoded JPN address-from characters are not displayed correctly in thread pane
Categories
(MailNews Core :: Backend, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M14
People
(Reporter: momoi, Assigned: scottputterman)
References
Details
(Whiteboard: [PDT+])
Attachments
(1 file)
66.51 KB,
application/octet-stream
|
Details |
** 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•25 years ago
|
QA Contact: lchiang → momoi
Reporter | ||
Comment 1•25 years ago
|
||
Assigned myself as teh QA contact.
Comment 2•25 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•25 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•25 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•25 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•25 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•25 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•25 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•25 years ago
|
Target Milestone: M9 → M11
Comment 8•25 years ago
|
||
changing TFV to M11.
Comment 9•25 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•25 years ago
|
||
I'm not doing anything with charsets.
Reporter | ||
Comment 11•25 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•25 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•25 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?)
Comment 14•25 years ago
|
||
(target milestone is M11 or M12 - add to mail beta tracking bug)
Comment 15•25 years ago
|
||
Comment 16•25 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•25 years ago
|
Assignee: mscott → putterman
Status: ASSIGNED → NEW
Target Milestone: M11 → M12
Assignee | ||
Comment 17•25 years ago
|
||
reassigning to me.
Reporter | ||
Updated•25 years ago
|
Severity: normal → critical
Reporter | ||
Comment 18•25 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•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12 → M14
Reporter | ||
Updated•25 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•25 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.
Reporter | ||
Comment 20•25 years ago
|
||
*** Bug 25176 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 21•25 years ago
|
||
*** Bug 25176 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 22•25 years ago
|
||
*** Bug 25176 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 24•25 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
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 25•25 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
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
•