281781 - the return value of WWW_GetWindowInfo is broken

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If the page is located IDN domain or have non-ASCII title,
the return value of WWW_GetWindowInfo is broken.
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsNativeAppSupportWin.cpp#1445
http://lxr.mozilla.org/seamonkey/source/toolkit/xre/nsNativeAppSupportWin.cpp#1024

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv1.0

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv1.1

Comment 3

[Jungshik Shin]

Comment on attachment 173960 [details] [diff] [review]
Patch rv1.1

r=jshin  

I'll file separate bugs on related issues :

We may be breaking things down the road as in the following:

http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsNativeAppSupportWin.cp
p#2314

In addition, we would be better off using CF_UNICODETEXT instead of CF_TEXT
here and passing PRUnichar (On Win 9x/ME, we have to convert to the native
encoding and use CF_TEXT) 

http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsNativeAppSupportWin.cp
p#1720

BTW, OS/2 code has the same issue.

Comment 4

[Jungshik Shin]

It's more complex than I thought when I filed bug 282285. Until we make our
DDE-code Unicode-aware, we definitely need to get the patch here in.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 173960 [details] [diff] [review]
Patch rv1.1

sr=bzbarsky

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 173960 [details] [diff] [review]
Patch rv1.1

The risk is low.

Comment 7

[Asa Dotzler [:asa]]

Comment on attachment 173960 [details] [diff] [review]
Patch rv1.1

a=asa for checkin to 1.8b

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Jungshik:

Could you check-in the patch?

Comment 9

[Jungshik Shin]

landed

Comment 10

[Darin Fisher]

This patch broke the Win32 seamonkey build.  The problem is that it uses
NS_CopyUnicodeToNative, which is implemented in xpcom_core.dll.  Unfortunately,
mozilla.exe does not link to xpcom_core.dll.  It is in fact loading XPCOM via
the glue stubs as a regular GRE client.  To solve this problem, I added code to
nsStringSupport.h that would in the #ifdef MOZILLA_STRICT_API case implement
NS_CopyUnicodeToNative in terms of NS_UTF16ToCString.  Please keep this in mind
if you are patching xpfe/bootstrap in the future.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sorry for build bustage.
But I have been able to build on my system... why?

Comment 12

[William Bumgarner [:zsinj]]

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