632370 - Unicode chars of CcList and BccList are not handled properly

Status: RESOLVED DUPLICATE of bug 77972

(MailNews Core :: Backend, defect)

Description

[Mizutori]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7

CcList and BccList attributes of the account settings are not handled properly if they have unicode characters.
(1) Unicode characters are saved to / loaded from the prefs.js in a wrong encoding.
(2) In message compose window, the Cc and Bcc fields are filled with wrong characters, especially after switching the account repeatedly.


Reproducible: Always

Steps to Reproduce:
(1) in saving/loading prefs.js
1. Fill the CcList / BccList fields of the account settings with unicode characters.
2. Press OK to save the settings.
3. Again, open the preference panel to confirm the fields.
4. Then, the CcList / BccList fields are filled with wrong characters.

(2) in message compose window
1. Edit prefs.js directly to set a unicode string to CcList / BccList attributes of the specified account in UTF-8 encoding.
2. Open a new message compose window, and switch the account to the specified one.
3. Then, the Cc / Bcc fields are filled with wrong characters.

Actual Results:  
(1) in saving/loading prefs.js
1. Wrong characters are saved to prefs.js from CcList / BccList fields.
2. Wrong characters are loaded from prefs.js to CcList / BccList fields.

(2) in message compose window
1. Cc / Bcc fields are filled with wrong characters. 


Expected Results:  
(1) in saving/loading prefs.js
Real unicode characters are expected to be saved to / loaded from prefs.js.

(2) in message compose window
Real unicode characters are expected to be set to Cc / Bcc fields.


My workaround for this problem is:

(1) in saving/loading prefs.js
Fix the saveAccount() / getAccountValue() functions of the source 
AccountManager.js to save / load the value of doCcList and doBccList attributes via UnicharAttribute() function, instead of accessing directly.

---[ AccountManager.js::saveAccount() ]---
dest[slot] = typeArray[slot];
-->
if (slot in {"doCcList":null,"doBccList":null})
dest.setUnicharAttribute(slot,typeArray[slot]);
---

---[ AccountManager.js::getAccountValue() ]---
accountValues[type][slot] = source[slot];
-->
if (slot in {"doCcList":null,"doBccList":null})
accountValues[type][slot] = source.getUnicharAttribute(slot);
---

(2) in message compose window
Fix the LoadIdentity() function of the source MsgComposeCommands.js
to access doCcList and doBccList attributes via UnicharAttribute() function, 
instead of accessing directly.

---[ MsgComposeCommands.js::LoadIdentity() ]---
prevCc += prevIdentity.doCcList
-->
prevCc += prevIdentity.getUnicharAttribute("doCcList");

newCc += gCurrentIdentity.doCcList;
-->
newCc += gCurrentIdentity.getUnicharAttribute("doCcList");
---
* Also, apply same patches to "doBccList" attributes.

Comment 1

[Mark Banner (:standard8)]

We don't currently support unicode characters in email addresses, so are you using them for names in the "name <email@address>" style?

Comment 2

[Mizutori]

(In reply to comment #1)
> We don't currently support unicode characters in email addresses, so are you
> using them for names in the "name <email@address>" style?

Yes, the "name" part is a unicode string, that occurs an error.
A simple "email@address" form in ascii code does not yield any problem.
I hope the thunderbird accepts "name <email@address>" form in future.

Comment 3

[Makoto Kato [:m_kato]]

we should use wstring instead of string in nsIMsgIdentity.idl

Comment 4

[Makoto Kato [:m_kato]]

Attachment: fix

Comment 5

[David :Bienvenu]

Comment on attachment 528068 [details] [diff] [review]
fix

thx for the patch. minusing, because this doesn't compile on the trunk:

NS_ConvertUTF8ToUTF16.

but the general approach seems fine. A unit test would be good, however.

Comment 6

[Mark Banner (:standard8)]

You could consider using nsAUTF8String which would avoid the need for utf-8 to 16 conversion.

Comment 7

[Makoto Kato [:m_kato]]

there is same issue for reply_to.  This will be fixed by that bug.