15201 - [DOGFOOD] Name completion does not display Latin 1 names correctly

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 9/29/99 Win32 build **

Currently it is possible to name complete non-ASCII names in the Address Book as long as the non-ASCII
characters do not begin the name string.
But when such names are completed, Latin 1 accented characters are incorrectly displayed. It looks
like Unicode bytes are displayed as raw bytes than converted to a single character which matches the
byte sequence.
Since the Address field widget can support non-ASCII display currently, we should be able to display such
characters correctly.

To reproduce this bug:

1. Create an AdBook card with names which contain some Latin 1 accented characters. You can input these
   by using Right-ALT key + 0 + 234 (on the keypad). "234" part can be any number above 128 but Latin-series
   accented characters range from 192 - 255.
2. Let's say we have something like "Mol_t" where the underscore indicates a Latin accented character. Then
   you can let Mozilla complete this name by entering Mol + [ENTER] -- if "Mol" identifies a unique entry.
3. Now take a look at the accented character, you will see a 2 character sequence of gibberish instead.

Comment 1

[hangas]

Jean-Francois, as we discussed I am sending this bug to you.  Marking as M11 at
the request of momoi.

Comment 2

[Katsuhiko Momoi]

To marina as QA contact.

Comment 3

[Jean-Francois Ducarroz]

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

Comment 4

[Jean-Francois Ducarroz]

move to M12 as is not doogfood (yet!)

Comment 5

[Katsuhiko Momoi]

It is [Dogfood] for international actually.
Note that this is a Basic Functional Item for the Mail/News team.
See:

http://slip/projects/seamonkey/mail/admin/m10_mail_test.html

It is also a Basic Funtcional item for us.
I suggest that we put it back on M11 list.

Comment 6

[msanz]

Jeff, we may discuss whether it is dogfood or not, but that's not reason to move
it to M12. Please, reconsider target milestone, since intl. needs this feature
in M11.

Comment 7

[Jean-Francois Ducarroz]

I've moved it to M12 as it is not a dogfood and as my M11 list is already pretty
big. If you really want it, mark it as a doogfood and then I will move it back
to M11. Anyway, I plan to do only dogfood (Mark as M11 or M12) for M11.

Comment 8

[Jean-Francois Ducarroz]

oops, it's already mark as dogfood. Move it back to M11

Comment 9

[lchiang]

Actually, the PDT team needs to review this bug.  They will mark PDT+ or PDT- on
the status whiteboard after review.

Comment 10

[daver]

Seems like autocomplete alone is on the edge of dogfood.  Not sure if you need
it in your functional test for Dogfood.

Comment 11

[msanz]

If autocomplete itself is not "dogfood", then this bug shouldn't be PDT+.

Comment 12

[Jean-Francois Ducarroz]

I have a fix for it, waiting on code review...

Index: nsAbAutoCompleteSession.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/addrbook/src/nsAbAutoCompleteSession.cpp,v
retrieving revision 1.13
diff -r1.13 nsAbAutoCompleteSession.cpp
208c208,213
< 				nsString searchResult(fullAddress);
---
>
> 				/* We need to convert back the result from UTF-8 to Unicode */
> 				PRUnichar* searchResult;
> 				PRInt32 searchResultLen;
> 				INTL_ConvertToUnicode(fullAddress, nsCRT::strlen(fullAddress), (void**)&searchResult, &searchResultLen);
>
210c215,216
< 				rv = aResultListener->OnAutoCompleteResult(aParam, aSearchString,
searchResult.GetUnicode());
---
> 				rv = aResultListener->OnAutoCompleteResult(aParam, aSearchString, searchResult);
> 				PR_Free(searchResult);

Comment 13

[Jean-Francois Ducarroz]

Code reviewed by mscott and bienvenu.
Fixed and checked in.

Comment 14

[marina]

verified in 2000-02-01-08 M14 Win build.