229379 - nsIProcess should be made scriptable and accept 'wstring'/'AString'

Status: NEW

(Core :: XPCOM, defect)

Description

[Wang Xianzhu]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.4) Gecko/20030624
Build Identifier: Most recent code

We can't pass international string to nsProcess.  For example, to let notepad
open a file whose name is in Chinese.

And there is no means for JavaScript to convert a Unicode string into native
charset.

I noted in nsIProcess.idl, this problem has been pointed out.

I think a helper component like 'nsNativeCharsetConverter' may help.  With its
help, we can just declare that the string types in nsIProcess.idl are in native
charset.  We can use JavaScript strings as transparent char containers.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Jungshik Shin]

I'm confused about what you want here. At first I thought you wanted to pass
along command line arguments outside the character repertoire of the current
system codepage on Windows. For instance, opening a file with  'Chinese' name
with notepad when the system locale is English or French. (opening a Chinese
file with notepad under Chinese locale works fine). 

Then, you went onto write something else. Can you tell me more about your need
to deal with 'native' character encoding in Javascript? 

Comment 2

[Wang Xianzhu]

For example, there is an input box in the XUL UI to let the user input a
filename into it.  The filename may contain Chinese characters which will be
encoded by JavaScript in UTF-16.  Then I use nsIProcess interface to launch
notepad to open the file.  This will fail, no matter the locale of the OS,
because nsIProcess only accepts char * string, and when XPConnect converts a
JavaScript string into char * string, it simply cast 16bit jschars into 8bit
chars, causing lost of string information.

There are either solutions:
1. Let nsIProcess support Unicode strings
2. Give JavaScript the ability to handle native strings. I have implemented this
by a wrapper component of NS_CopyUnicodeToNative/NS_CopyNativeToUnicode.

Comment 3

[Jungshik Shin]

Thanks for the clarification. Then, the summary line should be changed. I prefer 
the solution A to the solution B. That is, nsIProcess->run() should accept 
'wstring' or 'AString' instead of 'string'. There may be a bug that's been 
already filed on this issue. I'm confirming it for the now, but have to look for 
 a possible duep.

BTW, see also bug 227500

Comment 4

[Benjamin Smedberg]

Please be aware that nsIProcess is a hacked-together interface that ought to be
rewritten, perhaps significantly. In particular, there is ongoing work to set up
usable IPC pipes between applications that may affect this interface.

Comment 5

[Jungshik Shin]

any update on the work mentioned in the previous comment? If there's a bug filed on the issue, it'd be nice to make this bug depend on it.

Comment 6

[sf]

(In reply to comment #5)
> any update on the work mentioned in the previous comment? If there's a bug
> filed on the issue, it'd be nice to make this bug depend on it.
> 

I can also confirm this bug still exist, tested in Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

sample code to test it and verify the bug, and the error always reproduce:

netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

function test_nsIProcess(exefile, file)
{
	var exe=Components.classes['@mozilla.org/file/local;1'].createInstance(Components.interfaces.nsILocalFile);
	exe.initWithPath(exefile);
	if (!exe.exists()) {
		return;
	}
	var process=Components.classes['@mozilla.org/process/util;1'].createInstance(Components.interfaces.nsIProcess);
        var param = [];
	param.push(file); // add address
	process.init(exe);
	process.run(false, param, param.length); // launch executable
}

function openWithExe(exefile, file) {
  var exe = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
  exe.initWithPath(exefile);

  var ifile = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
  ifile.initWithPath(file);

  if (exe.exists() && ifile.exists()) {
    try {
      var mimeInfoService = Components
        .classes["@mozilla.org/uriloader/external-helper-app-service;1"]
        .getService(Components.interfaces.nsIMIMEService);
      var mimeInfo = mimeInfoService
        .getFromTypeAndExtension("", "" );
      mimeInfo.preferredAction = mimeInfo.useHelperApp;
      mimeInfo.preferredApplicationHandler = exe;
      mimeInfo.launchWithFile(ifile);
      return true;
    } catch (e) {
      alert(e);
    }
  }
  return false;
}

var exe = "c:\\windows\\system32\\notepad.exe";
var asc_file = "d:\\test.txt";  //filename with ascii text
var non_asc_file = "d:\\²âÊÔ.txt"; //filename with non-ascii text
test_nsIProcess(exe, asc_file); //working
test_nsIProcess(exe, non_asc_file); //not working

openWithExe(exe, asc_file); //working
openWithExe(exe, non_asc_file); //working

in above openWithExe which use nsIMIMEService as a temporary solution without changing the core code.

anyway, openWithExe only works if you just want to pass the filename as parameter. it don't work if you have more parameters need to be passed.

So the nsIProcess.run provide unique feature and still need to be fixed.

Anyone can take a look at this? this will help those users with non-english 
locale system.

Comment 7

[Davide Ficano]

This bug continues to exist also in
Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

Any idea or workaround?

Comment 8

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 9

[Davide Ficano]

I've implemented a Win32 XPCOM version that works with unicode strings, barely it is the same code of nsIProcess but call CreateProcessW instead of CreateProcess.

I'll use it in next ViewSourceWith release, I'm glad if somebody wants to test it