Closed Bug 496733 Opened 12 years ago Closed 12 years ago
IProcess does not execute process with the correct arguments or it is somehow blocking the child execution .
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 nsIProcess FF 3.5 beta 4 fails to calls a child process with the wrong or bad arguments. nsIProcess does it right on FF 3.0 series. Reproducible: Always Steps to Reproduce: 1. Install Cepstral David for Linux x86 from http://cepstral.com/downloads/ 2. Add the following code to the JS file in the extension: const File = Components.classes["@mozilla.org/file/local;1"] .createInstance(Components.interfaces.nsILocalFile); const SwiftPath = "/opt/swift/bin/swift"; File.initWithPath(SwiftPath); const SwiftProcess = Components.classes["@mozilla.org/process/util;1"] .createInstance(Components.interfaces.nsIProcess); SwiftProcess.init(File); var args = new Array(); args = "-n"; args = "David"; args = "-m"; args = "text"; args = "Test"; SwiftProcess.run(false, args, args.length); 3. The David voice should speak the text as on FF 3.0 series. Actual Results: The David voice should speak the text as on FF 3.0 series but with FF 3.5b4 for Linux x86 nothing happens. Possible mingling of arguments. Could also be some other problem. Expected Results: The David voice should speak the text as on FF 3.0 series. I am sure that this problem can be recreated by calling other child processes.
Can you reproduce this with a latest-nightly? They're available here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/
I've tested the code provided using the Cepstral app on current trunk, 1.9.1 branch and 3.5b4 and in all cases I heard the same output as I hear when running the app from the normal command line, so I cannot reproduce this issue. Additionally we have automated tests in tree that verify argument passing to applications using nsIProcess and these have been passing. Admittedly they only test a single argument but that could be improved easily. Are you able to produce a small example extension that demonstrates the problem that we can test with (just some js code attached to a menu would be perfect), rather than working off code snippets?
This just extends the existing tests by making sure we handle multiple arguments correctly (6 of them here). It passes on all platforms on the try server.
Attachment #382046 - Flags: review?(robert.bugzilla)
Not blocking until we get get a confirmation or solid steps to reproduce here. Maybe Linux-only? Please re-nominate once the issue gets narrowed down.
Flags: blocking-firefox3.5? → blocking-firefox3.5-
Attachment #382046 - Flags: review?(robert.bugzilla) → review+
Comment on attachment 382046 [details] [diff] [review] improve unit tests [checked in] Landed these tests: http://hg.mozilla.org/mozilla-central/rev/96393f6850f9 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cf479e101ec2
Attachment #382046 - Attachment description: improve unit tests → improve unit tests [checked in]
As I expected these tests are passing on all platforms on both trunk and branch. We'll need some more specific details to go on before we can work out what might be going wrong here
It occurred to me that we don't have tests for passing arguments with spaces or quotes and given the lengths that we have to go to on windows to do that we should check it is working. This passes on try server.
Attachment #384115 - Flags: review?(robert.bugzilla)
Attachment #384115 - Flags: review?(robert.bugzilla) → review+
Comment on attachment 384115 [details] [diff] [review] additional tests [checked in] Landed: http://hg.mozilla.org/mozilla-central/rev/28aa23105a9e http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1b03097479af
Attachment #384115 - Attachment description: additional tests → additional tests [checked in]
Based on a lack of further communication from the bug reporter on how to reproduce this and because the added tests are all passing on both branches I'm going to close this as WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.