bookmarks don;t correctly import and display Japanese bookmarks from the IE Favorties list. Instead of seting the bookmark in the bookmark title, you have garbage (mojibake) latin-1 characters.

Add dependency on 9171, which is targeted to be fixed in M9.

Move to M10.

Giving Robert the bookmarks love since I can't deliver.

Tague, can you provide me with an example of a URL that when bookmarked in IE, we don't import and display properly? I played around with this, and it appeared that for JA sites [with non-latin titles] it would set the bookmark's name to be the same as the URL [which is 7-bit].

www2.nikkei.co.jp/channelJ/nikkeiJ.cdf channel.mainichi.co.jp/maichan.cdf these are pre-seeeded bookmarks installed with IE on japanese systems (still occuring with today's build)

Tague, are you using IE 5 or a previous version? I can't seem to reproduce this under either Win98 or WinNT. (As I mentioned previously, for me IE 5 seems to be storing the URL as the name for foreign charsets.) I believe I've installed the foreign language support kits properly, but hey, you never know. Perhaps I can come and look at it on your machine?

rjc :- feel free to come down and look at the machine any time. i'm using IE5 and this is happening with a completely new profile. /t

msanz, can you qa assign this to someone on your team?

reassigning qa to teruko

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

The fix should be very similar to the fix of 20817. We should use nsIPlatformCharset to convert the IE Favor

Added beta1 in keywords.

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

PDT-

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

I add me to Cc: This occurs since XPCOM (nsFileSpec) don't have PRUnichar interface. PRUnichar interface need nsFileSpec. See ftang's commnet of BUG 5887

M15

When M14 is going to be NS branded beta then this bug should be targeted for M14. This must work for IE users who will try new NS.

Tague, can you apply this patch and see if it works for you? (I think that you're a good candidate for testing it, since you originally reported the problem. :)

Sorry, I forgot that It calls nsCRT::free(). please fix it. void nsFileSpec::GetLeafUniName(nsString &nativePathString) { char * path = GetLeafName(); if (nsnull == path) { nativePathString.SetString(""); return; } else { PRUnichar *converted = ConvertFromFileSystemCharset(path); if (nsnull != converted) { nativePathString.SetString(converted); delete [] converted; } else nativePathString.SetString(path); nsCRT::free(path); } }

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

And [$B%=%U%H%&%'%"$N99?7(B] is display as [$B%U%H%&%'%"$N99?7(B]. If it uses [0x5c] at DBCS seconed characor, it seems not to be able to display...

tague is no longer working for Netscape nor Mozilla.

Yes m_kato's patch work fine in my Japanese NT. Howerver, two comments 1. I suggest we still call the function GetLeafName, not GetLeafUniName. ALL the interface SHOULD be nsString/PRUnichar*. 2. about the 5c problem. Can you solve this in a cross platform way ? My suggestion is check in m_kato's patch (with the name changed) and rewrite this function to make it work cross platform later. Add nhotta to cc list. Please reconsider this as beta1. PDT team- see the screeshot - http://warp/u/ftang/tmp/image3DT.JPG Reassign back to rjc ( tague is no longer work for Netscape ) since 1/2 of the fix is in the rdf code.

Doug, please review this patch to nsFileSpec... after approving it (or not), then reassign this bug back to me.

0x5c problem is only Windows and OS/2. GetLeafName() uses in Editor, too (BUG 28591). GetLeafName() should have nsString or PRUnichar*.

> 0x5c problem is only Windows and OS/2. hum ? how about Mac / Linux ? in Shift_JIS or BIG5 ?

[0x5C] - "\" is path separator of Windows and OS/2. Unix is [0x2F] - "/". Mac is [0x3A] - ":". Second charactor of DBCS (CP932, CP936, CP949 and CP950) uses "\". But it doesn't use '/' and ":" EUC doesn't uses "\", "/" and ":". So, the following needs... o Path separator is "\" (Windows and OS/2). o Filesystem encoding is CP932(Japanese - Shift JIS), CP936(Simplified Chinese - GB), CP949(Korean - KSC 5601) or CP950(Traditional Chinese - BIG-5). So, Mac and Linux (Unix) don't meet!!

Putting on PDT- radar for beta1.

I simply do not understand why PDT team put a PDT- on a bug like this. Remove the PDT- and ask for reconsideration. See http://warp/u/ftang/tmp/image3DT.JPG for the garbage text in the bookmark and sidebar. I will feel very very very embrassed if we ship a beta like this.

dougt, have you had a chance to review these changes? (I'd like your review as you own nsFile/nsFileSpec)

I would rather you use nsIFile. if this is a PDT+ bug, go ahead and check in. r=dougt.

Called ftang to get more info.

assigning to ftang

Putting on PDT-, will add relnote for IE bookmarks problem. "IE Favorites are not usable in the sidebar or menu selections on international systems." If you get a patch that works, let us know.

reassign back to rjc as his 2000-02-21 14:05 comment. I try the patch in my system for serverl days and it work very nice. I think we should take it.

As long as this is PDT-, I won't be checking it in until the tree opens for M15... so if anyone wants to continue trying to get approval from the PDT team for this to become a PDT+ bug, feel free to try by removing the PDT- status.

Cleared PDT- for reconsideration. The existing patch has been tested by ftang in his local build. rjc and ftang, Have you both reviewed the patch?

r=ftang

Another [PDT+] bug needs this fix too. Bug 7844 "JPN Local Mail folder names do not show correctly"

If this is really needed for 7844, PDT+. cc'ing putterman.

Fixed. Note: per ftang, the additional function is: GetLeafName(nsString);

I verified this in 2000022909 Win32 build.

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

Reopening. Occurs on 2000052008 nightly build on Windows 2000.

Frank, can you look at this? (Since you guess coded up the last fix.)

frank. dup of bug 38887 patch is already on bug 38887

The bug is still "New". Let's mark it resolved/duplicate per m_kato's comment in Bug 38887. *** This bug has been marked as a duplicate of 38887 ***

Verified as dup.