Wrong arguments passed to browser on OS X

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Specify a browser on OS X, with additional arguments. eg 
"Applications/Google Chrome.app/Contents/MacOS/Google 
Chrome;--disable-restore-session-state;--homepage;about:blank"
2. watch the browser not launch.
3.

What is the expected output? What do you see instead?

Expected browser to launch with the specified options. It just hangs.

What version of the product are you using? On what operating system?

OS X Lion

Please provide any additional information below.

This is a bug in CommandLineBrowserRunner. Instead of launching the command I 
specify, it's adding an additional (and completely unnecessary) 'open -a' in 
front of the command. This doesn't work because 'open' requires a '--args' 
before arguments to the browser (which incidentally would be a better approach 
for jstestdriver rather than this semicolon-separator hack).

Since the wrong command just exits with usage information - and jstestdriver 
doesn't trap stdout/stderr in a separate thread, the process will hang waiting 
for something to consume its output.

I can work around it by changing the command line to:

"Applications/Google Chrome.app/Contents/MacOS/Google 
Chrome;%s;--args;--disable-restore-session-state;--homepage;about:blank"

Or:

"Applications/Google 
Chrome.app;%s;--args;--disable-restore-session-state;--homepage;about:blank"

Note the extra %s and --args. jstestdriver doesn't print what it was trying to 
execute, even in debug mode, so you have to read the source to figure out what 
it did here.

The use of 'open' here is unnecessary; an OS X developer can always supply that 
command if they need it. It doesn't even support opening the *default* os x 
browser, which would mean not sending the '-a'. Please consider a saner setup, 
eg make '--browser' the last argument to jstestdriver and pass any remaining 
args to the browser command; with no special case for OSX. Or if you have to 
maintain backward compatibility, only do this 'open -a' stuff when the named 
browser is a directory.

Original issue reported on code.google.com by brian.ew...@gmail.com on 26 Apr 2012 at 12:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This issue is at odds with 
http://code.google.com/p/js-test-driver/issues/detail?id=97.

Original comment by corbinrs...@gmail.com on 6 Jun 2012 at 12:25

[GoogleCodeExporter]

The problem is, with the old system, people who wanted to use open -a still 
could (via a wrapper script or whatever). With the new system, people who don't 
want to use open -a have no choice.

Firefox and Chrome on mac support command line switches; issue 97 is re Safari, 
because it doesn't. Given that that's the case, changing the startup behaviour 
of Safari involves writing an applescript wrapper anyway, and adding open -a 
just makes inserting this wrapper *harder*. eg, the behaviour below, closing 
tabs in safari, can't be done without a wrapper (I do this in chrome by 
starting the browser --incognito)

#!/bin/sh
# A selection of things you might want to do to Safari
# Close open instances
killall Safari
# clear the caches
rm -rf ~/Library/Caches/Safari/*
# Start it back up...
open -a Safari
# ...without any open tabs
osascript -e "tell application \"Safari\" to close every window"
# NOW capture the browser
osascript -e "tell application \"Safari\" to open location \"$1\""

Original comment by brian.ew...@gmail.com on 6 Jun 2012 at 1:18

[GoogleCodeExporter]

It's a damned if I do and damned if I don't.

Since I can't find much documentation on open, maybe you can answer this: can 
open be used on apps outside /Applications?

Original comment by corbinrs...@gmail.com on 6 Jun 2012 at 2:27

[GoogleCodeExporter]

Yes, you can use the full path to the app directory (including the '.app' 
extension). If anything, that's preferable.

As far as I can tell, open is a small wrapper around Apple's Launch Services.
https://developer.apple.com/library/mac/#documentation/Carbon/Reference/LaunchSe
rvicesReference/Reference/reference.html

The paths we're interested in always end up calling LSOpenURLsWithRole. This 
takes a LSApplicationParameters reference, which includes an application's 
filename. This filename comes from a call to LSFindApplicationForInfo. This 
takes a bundle id and/or a filename to search for; my guess is open passes its 
'-a' argument to both.

Original comment by brian.ew...@gmail.com on 6 Jun 2012 at 3:46