Closed Bug 6770 Opened 25 years ago Closed 24 years ago

illegal use of nsString- Bookmarks don't correctly import Japanese/Hebrew bookmarks from the IE Favorties List

Categories

(Core Graveyard :: RDF, defect, P3)

Product:
Core Graveyard
Component:
RDF
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 38887

People

(Reporter: tague, Assigned: ftang)

References

Details

(Keywords: relnote, Whiteboard: [PDT+] reviewed fix ready)

Attachments

(2 files)

a patch. please verify!
2.71 KB, patch
Details | Diff | Splinter Review
a new patch of nsFileSpec.cpp (include prev commment fix)
2.14 KB, patch
Details | Diff | Splinter Review 
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.
Status: NEW → ASSIGNED
Target Milestone: M8
Blocks: 7577
Depends on: 9171
Target Milestone: M8 → M9
Add dependency on 9171, which is targeted to be fixed in M9.
Blocks: 11417
Target Milestone: M9 → M10
Move to M10.
Assignee: waterson → rjc
Status: ASSIGNED → NEW
Giving Robert the bookmarks love since I can't deliver.
Status: NEW → ASSIGNED
Target Milestone: M10 → M12
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?
Target Milestone: M12 → M14
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
QA Contact: phillip → msanz
msanz, can you qa assign this to someone on your team?
QA Contact: msanz → teruko
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.
Keywords: beta1
*** Bug 26223 has been marked as a duplicate of this bug. ***
PDT-
Whiteboard: [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
Summary: Bookmarks don't correctly import Japanese bookmarks from the IE Favorties List → Bookmarks don't correctly import Japanese/Hebrew bookmarks from the IE Favorties List
M15
Target Milestone: M14 → 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.  :)
Assignee: rjc → tague
Status: ASSIGNED → NEW
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.
Assignee: tague → rjc
Whiteboard: [PDT-]
Blocks: 28424
Doug, please review this patch to nsFileSpec... after approving it (or not), 
then reassign this bug back to me.
Assignee: rjc → dougt
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 ?
Summary: Bookmarks don't correctly import Japanese/Hebrew bookmarks from the IE Favorties List → illegal use of nsString- Bookmarks don't correctly import Japanese/Hebrew bookmarks from the IE Favorties List
[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.
Whiteboard: [PDT-]
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.
Whiteboard: [PDT-]
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.
Whiteboard: [NEED INFO]
assigning to ftang
Assignee: dougt → 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.
Keywords: relnote
Whiteboard: [NEED INFO] → [PDT-]
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.
Assignee: ftang → rjc
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.
Status: NEW → ASSIGNED
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?
Whiteboard: [PDT-]
r=ftang
Another [PDT+] bug needs this fix too.
      Bug 7844 "JPN Local Mail folder names do not show correctly"
Blocks: 7844
Whiteboard: reviewed fix ready
If this is really needed for 7844, PDT+. cc'ing putterman.
Whiteboard: reviewed fix ready → [PDT+] reviewed fix ready
Blocks: 28591
Fixed.

Note: per ftang, the additional function is:  GetLeafName(nsString);
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I verified this in 2000022909 Win32 build.
Status: RESOLVED → VERIFIED
*** Bug 22116 has been marked as a duplicate of this bug. ***
Reopening.
Occurs on 2000052008 nightly build on Windows 2000.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Frank, can you look at this?  (Since you guess coded up the last fix.)
Assignee: rjc → ftang
Status: REOPENED → NEW
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 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Verified as dup.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: