Unable to locate "firefox"

[lembark]

May be mis-worded error since I can start firefox from the command line. SSH from desktop into server running selenium (telnet localhost 4444 connects). "whereis" shows firefox (symlink), "firefox -new-instance" starts firefox.

Acquiring new S::R::D instance fails however (see below).

Q: Is this be related to running over ssh with the display set back (i.e., message is a red herring)? Q: Is there anyplace in the constructor to pass in an absolute path (I see "browser_name" but that seems to be looking for a basename not an absolute path)? thanks

Example:

my $driver  = Selenium::Remote::Driver->new
(
    qw( default_finder  css )
);

Could not create new session: Cannot find firefox binary in PATH. Make sure firefox is installed. OS appears to be: LINUX Build info: version: '2.46.0', revision: '87c69e2', time: '2015-06-04 16:16:47' System info: host: 'dizzy', ip: '192.168.1.2', os.name: 'Linux', os.arch: 'amd64', os.version: '4.1.0-aufs.ae', java.version: '1.7.0_79' Driver info: driver.version: FirefoxDriver at (eval 35)[/opt/perl/5.22/lib/site_perl/5.22.0/Sub/Quote.pm:3] line 508. at /opt/perl/5.22/lib/site_perl/5.22.0/Selenium/Remote/Driver.pm line 410. Selenium::Remote::Driver::_request_new_session(Selenium::Remote::Driver=HASH(0x24e3c88), HASH(0x4108578)) called at /opt/perl/5.22/lib/site_perl/5.22.0/Selenium/Remote/Driver.pm line 372 Selenium::Remote::Driver::new_session(Selenium::Remote::Driver=HASH(0x24e3c88), HASH(0x40232e8)) called at /opt/perl/5.22/lib/site_perl/5.22.0/Selenium/Remote/Driver.pm line 236 Selenium::Remote::Driver::BUILD(Selenium::Remote::Driver=HASH(0x24e3c88), HASH(0x24e3b50)) called at (eval 35)[/opt/perl/5.22/lib/site_perl/5.22.0/Sub/Quote.pm:3] line 508 Selenium::Remote::Driver::new("Selenium::Remote::Driver", "default_finder", "css") called at selenium-test line 5

Current path is: DB<1> x $ENV{ PATH } 0 '/images/bin:/home/lembark/bin:/opt/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4'

Which does include ":/usr/bin/:". Checking for firefox:

$ whereis firefox firefox: /usr/bin/firefox /usr/lib64/firefox $ ls -l /usr/bin/firefox lrwxrwxrwx 1 root root 26 Jul 8 19:53 /usr/bin/firefox -> /usr/lib64/firefox/firefox $ ls -l /usr/lib64/firefox/firefox -rwxr-xr-x 1 root root 109368 Jul 8 19:53 /usr/lib64/firefox/firefox

"firefox --new-instance" starts a new window.

[gempesaw]

Q: Is this be related to running over ssh with the display set back (i.e., message is a red herring)?

Huh, that's not the error message I'd expect if webdriver were complaining about the DISPLAY. But, yes, you've seized upon another issue running headless firefox - you'll need to convince it that you do have a display. I think the way I do it for my VMs looks like

DISPLAY=:1 xvfb-run --auto-servernum java -jar /path/to/selenium/selenium-server-standalone-2.46.jar

Pretty sure this won't solve your current issue, but once you get it resolved, that may be service afterwards if webdriver complains about being headless.

Q: Is there anyplace in the constructor to pass in an absolute path (I see "browser_name" but that seems to be looking for a basename not an absolute path)?

Not in the Selenium::Remote::Driver constructor that you're using. That POSTs for a new session to the webdriver server, which does its own lookup for the firefox binary on its own. Linux sometimes puts firefox in weird places, but /usr/bin/firefox is a pretty standard place so I am surprised it wouldn't find it.

Another option is to use Selenium::Firefox which should let you specify a binary path. However, I've never tried Selenium::Firefox headless, so I have no idea if it'll work or not.

Another thing you can try is going to the web page that the selenium server renders at http://

:4444/wd/hub/static/resource/hub.html . For localhost, it'd be http://localhost:4444/wd/hub/static/resource/hub.html - they have a little GUI for creating browser sessions, just another way to look at the problem. I'd expect it to give the same error message, but if it doesn't, that might be telling :)

[lembark]

The test was not running headless, the display was re-directed to a display that was already managing a copy of firefox. Stopping the firefox on the manager side solved the problem, hence my theory that the message is a red herring: it found firefox but got a non-zero exit from /path/to/firefox. Adding an explict "-x" test prior to forking might help explain what was going on.

Annoying thing is that since I've stopped and re-started the second copy of firefox I havn't been able to re-produce the error, so at this point the only thing to do is chalk it up to poltergeists [you did burn the goat hair at the last full moon before coding, I hope?].

Thanks for the input on dealing with headless testing. Be a great topic for next year's YAPC :-)

[gempesaw]

ah, i was a bit short on goats last month, was hoping the gods wouldn't notice. drat!

thanks for the update :)