243618 - Windows registry (non-ascii values) for MAPI are garbled

Status: RESOLVED FIXED

(MailNews Core :: Simple MAPI, defect)

Description

[Jungshik Shin]

Spin-off of bug 232969.

In bug 232969, I fixed a problem with storing non-ASCII string values in Win
registries. A similr problem exists at

http://lxr.mozilla.org/mozilla/source/mailnews/mapi/mapihook/src/nsMapiRegistryUtils.cpp#148

Comment 1

[Jungshik Shin]

Issac, is this bug identical in its nature to bug 232969? That is, I'm wondering
if we're pretending UTF-8 strings are in the system code page (e.g. Windows-949
on Korean windows) and putting UTF-8 strings in Windows registries. If that's
the case, I'll make a quick patch that works for characters within the
repertoire of the current system locale. I can deal with characters not covered
by the current system code page later (after resolving bug 239279)

Comment 2

[Isaac Hwak Han]

> is this bug identical in its nature to bug 232969?

Yes. On WinXP, raw UTF-8 string is put into registry, although the Win-registry
engine parses it as USC2. I'll attach a screenshot demonstrating this. On Win9x,
I guess it would be saved in the locale-specific system code page.

Comment 3

[Isaac Hwak Han]

Attachment: Garbled Text

If |defaultMailDisplayTitle| in messenger-mapi/mapi.properties are localized to
"%S 메일", the application string in Start Menu is garbled. The same garbled
text appears in various places, such as Control Panel/Internet
Options/Programs.

Comment 4

[Jungshik Shin]

(In reply to comment #2)
> Yes. On WinXP, raw UTF-8 string is put into registry, although the Win-registry
> engine parses it as USC2. I'll attach a screenshot demonstrating this. 
> On Win9x,
> I guess it would be saved in the locale-specific system code page.

Thanks for the confirmation. On both Win 2k/XP and Win 9x/ME, UTF-8 strings are
 put into registries with 'A' APIs which expect strings in the locale code page
instead of UTF-8. So, this bug is of exactly the same nature as bug 232969 and
bug 240272. 

I'll make an _interim_ patch that will make Mozilla handle characters covered by
the locale code page correctly. It's possible to branch the code into two, Win
9x/ME and Win 2k/XP based on the run time detection of the OS to take full
advantage of Unicode support on Win 2k/xp, but I'd rather not do it that way.
Once bug 239279 is resolved, it should be easy enough to make use of Win2k/XP's
Unicode capability. 

Comment 5

[Jungshik Shin]

Attachment: patch (not yet tested)

Patch. if you can test it, it'd be great. Otherwise, i'll test it later.

Comment 6

[Jungshik Shin]

Attachment: patch update

This should do.

Comment 7

[Isaac Hwak Han]

Comment on attachment 151739 [details] [diff] [review]
patch update

I tested the patch on WinXP, and it worked great. Thanks.

Comment 8

[Jungshik Shin]

Comment on attachment 151739 [details] [diff] [review]
patch update

thanks for testing.
asking for r/sr.

Comment 9

[David :Bienvenu]

Comment on attachment 151739 [details] [diff] [review]
patch update

thx for doing this.

Comment 10

[Jungshik Shin]

This is rather a trivial fix with a low risk factor that I think should go in
for aviary-1.0 bracn and 1.7 branch as well as the trunk.

Comment 11

[Jungshik Shin]

Comment on attachment 151739 [details] [diff] [review]
patch update

asking Neil for sr

Comment 12

[[e-mail]]

Comment on attachment 151739 [details] [diff] [review]
patch update

Presumably these conversions can be removed once we have the aforementioned
unicode api handling the conversions that 95/98/Me require.

Comment 13

[Jungshik Shin]

Comment on attachment 151739 [details] [diff] [review]
patch update

thansk for r/sr
asking for a1.7

this is a rather trivial fix that makes Mozilla properly deal with non-ASCII
values in Windows registry until we convert Mozilla-Win to be
fully-Unicode-capable (when we can get rid of the conversion and use
Unicode/'W' APIs directly). Similar patches for other parts of Mozilla already
have been checked in to 1.7branch.  

Affected users: Users of localized versions of Mozilla-Win

Comment 14

[Scott MacGregor]

Attachment: thunderbird 1.0 branch fix

the thunderbird 1.0 branch uses a very different looking
nsMapiRegistryUtils.cpp. I tried to re-write this patch by hand. Hopefully I
didn't make any mistakes or mis any of the new patterns :)

Comment 15

[Jungshik Shin]

Attachment: additional patch for aviary-1.0 branch

thanks for review and fixing it on TB 1.0 branch. I didn't expect the branch to
be that much different from seamonkey 1.7 branch. anyway, here are a few more
changes missed in the latest check-in (attachment 152485 [details] [diff] [review]). 

I haven't yet tested (haven't even compiled on Windows) this patch. I'm not
sure I have sufficient disk space on my Windows box for yet another build and
source tree.

Comment 16

[Mike Kaply [:mkaply]]

Comment on attachment 151739 [details] [diff] [review]
patch update

a=mkaply

Comment 17

[Scott MacGregor]

attachment 152496 [details] [diff] [review] now checked into the aviary 1.0 branch as well. Thanks for the
supplemental patch jshin. I added a missing semi colon to make it compile. 

Comment 18

[Jungshik Shin]

thansk for a1.7. checked into 1.7branch.

I changed my mind and am resolving this bug as fixed (to avoid unnecessarily
blocking 1.7* and aviary 1.0*).  I'll file a new bug  about switching over to W
APIs for registry handling once bug 239279 is resolved.