Closed Bug 20405 Opened 25 years ago Closed 25 years ago

[DOGFOOD] Non-ASCII data for account name/identity/org is not displaying correctly

Categories

(SeaMonkey :: MailNews: Account Configuration, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Account Configuration
Platform:
All
Windows 95
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ji, Assigned: alecf)

Details

(Whiteboard: [PDT+] Waiting for fix for 20929 for verification)

Attachments

(1 file)

prefs.js file containing Japanese identity and org name
2.00 KB, text/plain
Details 
Currently, the user can enter non-ASCII data for account name,
identity and organization name. But the original data is not
displaying correctly after saving it.

Steps of repro:
1. Select menu Edit | Account Setup... from Messenger.
2. Enter Japanese characters in the account name, identity and
   organization field and save the data by clicking on OK button.
3. Bring up the account manager again by selecting Edit | Account Setup...
   you'll see the Japanese account name displays as dots and
   identity and organization are garbled.
QA Contact: lchiang → ji
How are they saved in pref.js? In order to work correctly, they should be saved
as UTF-8.
The data is saved in UTF8 in prefs.js, but not converted back when displaying it.
As a point of comparison, Address Book names in Japanese
are preserved correctly from session to session and they
seem to be in UTF-8. prefs.js seems to be using UTF-8 in general.
Assignee: nhotta → phil
Missing charset conversion?
Reassign to phil.
Assignee: phil → alecf
Summary: Non-ASCII data for account name/identity/org is not displaying correctly → [DOGFOOD] Non-ASCII data for account name/identity/org is not displaying correctly
Reassign to alecf, and nominate for Dogfood, since this is data loss.
hrm.. this may have something to do with the fact that we save these in prefs,
and the API is "string" not "wstring".

How did we save non-ASCII prefs in 4.x?
Whiteboard: [PDT+]
Putting on PDT+ radar.
Status: NEW → ASSIGNED
Target Milestone: M12
In 4.x, there was no uniformity in encoding of the saved data.
Local Personal Address Book folder names were stored in the
system charset, while LDAP-related names & such were
store in UTF-8.
I guess I better mark this M12 then...:)
curses! I guess it's time to add SetUnicodePref()/CopyUnicodePref() to the Pref
API....

How do I convert a PRUnichar into UTF8 so that I can store it in prefs.js?
StreamConverter. CC ftang
Or nsString::ToNewUTF8String.
I need to go the other way too, how do I go UTF->PRUnichar?
There is a tricky one (but it works) nsTextFormater::smprintf.
see http://lxr.mozilla.org/seamonkey/source/xpcom/ds/nsTextFormater.h.
thanks... I'll use that for now, but if you know of one that doesn't
copy/convert the string 4 times, let me know :)

I should be able to check this in today. I'll send out code for a code review
later today.
Priority: P3 → P1
ok, I've checked in the pref changes, now I'm working on the mail side of
things.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
ok, mail-specific stuff has now been checked in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
With today's linux build, the account name is still displaying
as dots. And there is no entry saved in prefs.js file for account name.
Reopened it.
Status: REOPENED → ASSIGNED
How can I enter some unicode data into the text field so I can do more extensive
testing? I just have a standard redhat Linux box...

Also, the account name is stored in kind of a wierd place - in
mail.servers.<serverkey>.name
I attached a prefs.js file containing Japanese identity and org name.
You can install Japanese package on RH6.0 to be able to enter Japanese.
The related documentation is at
http://babel/projects/seamonkey/planning/Ender/kinput2/

Or if you like, you can drop me an email so I can telnet your machine and do the installation for you
Just to confirm - the Japanese in the prefs is in UTF8? (I don't know enough
about this to recognize it)
Yes. It is in UTF8.
ok, I got everything installed and even managed to enter some japanese.

Everything seems to be working though... I can enter japanese characters, close
the window, reopen it, and it still has the japanese characters...and when I
look in my prefs, I have stuff like this:
user_pref("mail.identity.id1.fullName", "Alec Flettç¾");

which looks like UTF to me... are you sure you had today's build? the daily
builds were delayed because of network problems, are you sure you didn't grab
yesterday's build?
yup, and even when I restart, I still have the same japanese characters in my
fullname. I'm going to test organization now.
aha! so I figured out the issue. I forgot to convert the server name, but
fullName and Organization work just fine. I'll have a fix for this in a moment.
is there an equivalent of strcmp for PRUnichar?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
ok, fix checked in.
Due to bug 20929, which doesn't allow user to change the default account name,
I can't verify the fix.
yup... it was fixing this that broken #20929 :)
(thanks for not reopening this though, I think leaving this unverified is the
right thing to do)
Whiteboard: [PDT+] → [PDT+] Waiting for fix for 20929 for verification
Status: RESOLVED → VERIFIED
Verified with 1999120708-M12 Linux build. It is fixed.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: