User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: CVS HEAD because the argv/argc and nsiCommandLine stuff doesn't use the windows unicode versions, any unicode filenames passed via the command line aren't usable. the MOZ_REMOTE guts suffer from the same issue as they pass the non-unicode command line and working directory via an WM_COPYDAYA, losing unicode paths. Reproducible: Always Steps to Reproduce: 1. Create a file with non-latin characters in the name 2. Create a command line handling xpcom component (one that implements nsICommandLineHandler) 3. Drag the file onto the xulrunner stub Actual Results: The filename gets mangled into question marks Expected Results: The filename is preserved and can be used to access the file a patch is attached. this is against CVS HEAD from a few days ago. the code is probably not 'correct', but it works. i need some pointers on how to do it 'right' :)

Can you make this into one patch against the trunk (HEAD)?

I believe that almost all of this work is already underway in bug 396052.

you're right - seems to be a lot of overlap with that bug. will try applying that patch tomorrow and see if it resolves all my issues.

Comment on attachment 293267 [details] [diff] [review] Single patch against HEAD Yeah, I think my version is better, and as far as I can tell this only handles the remoting case (second launch), not the initial-launch case where arguments come in from main()

this handles the initial case too: +#ifdef XP_WIN + + PRUnichar **szArglist; + int nArgs; + + szArglist = CommandLineToArgvW(GetCommandLineW(), &nArgs); + + rv = cmdLine->InitW(nArgs, szArglist, + workingDir, nsICommandLine::STATE_INITIAL_LAUNCH); + + LocalFree(szArglist); + +#else rv = cmdLine->Init(gArgc, gArgv, workingDir, nsICommandLine::STATE_INITIAL_LAUNCH); + +#endif + the main difference is that you pass around UTF8 while my patch passes around wide strings. means you don't need to add extra methods, but i avoided the manual parsing of the command line in the remoting handler by using CommandLineToArgvW(). your patch deals with the updater etc. though, so is almost certainly much better :)

Fixed by bug 396052 and some followups.