nsLocalFileWin's DirectoryEnumerator implementation is using PR_OpenDir and PR_ReadDir, which makes any non-ASCII characters in filenames be returned as '?' as it's calling FindFirstFile/FindNextFile internally. It needs to use PR_OpenDirUTF16/PR_ReadDirUTF16 if they don't return not implemented. This is causing import of IE bookmarks with non-ASCII characters in them to fail, e.g. bug 235495.
Created attachment 161100 [details] [diff] [review] 262922-localfilewin-utf16-0.patch Here's a first cut at a patch... of course, the problem is that we don't seem to build firefox with MOZ_UNICODE, so I'm kinda stuck here for fixing the depending bug...
vlad: yeah, there's a reason why MOZ_UNICODE is not defined. those APIs are experimental. see bug 239279 for all the gory details, and the solution that has been proposed.
Ugh. Any ideas for possible solutions to bug 235495 then? We're getting bogus data out of nspr right now.. I guess as a 1.0 bandaid, I can maybe do the function lookup for the unicode functions myself in nsIEProfileMigrator and use them directly instead of the enumerator, but that's getting rather gross. Not sure what else to do, though. (Also: attached patch has a bug; the Init method needs to use the right string, either GetPath or GetNativePath, instead of always using the Native method to get a CString.)
Was this fixed by bug 162361?
yes, it must have been.