I am using firefox v 48.0.2 and am trying to get my selenium (selenium-server v2.53) remotedriver automated tests to run on firefox, I have geckodriver 0.9.0 installed and when i go through the documentation on the github readme and run this command: (on mac osx 10.11.3)
geckodriver -b /Applications/FirefoxNightly.app/Contents/MacOS/firefox-bin
i get this error message:
thread '< main >' panicked at 'called Result::unwrap() on an Err value: Io(Error { repr: Os { code: 48, message: "Address already in use" } })', ../src/libcore/result.rs:746
note: Run with RUST_BACKTRACE=1 for a backtrace.
ive tried ignoring this step but when i run my tests firefox does not launch, i have ensured that my webdriver capabilities include marrionette: true
WebDriver:
browser: 'firefox'
clear_cookies: false
restart: false
window_size: 414x736
marionette: true
other than that i can not find any documentation to lead me in the correct direction, did i perhaps over look something? any help is greatly appreciated!
I am also using codeception to handle my tests (php)
EDIT
I was able to get this command to work after killing the process that was listening on port 4444:
geckodriver -b /Applications/FirefoxNightly.app/Contents/MacOS/firefox-bin
But even with that running Firefox is still not launching
Related
I'm using webdriverIO for some automation testing and have recently migrated from 'selenium-standalone' service to default wdio devtools protocol.
wdio v.7.16.12
firefox v.95.0.2
From that point I can't start testing with firefox browser:
INFO #wdio/cli:launcher: Run onPrepare hook
INFO #wdio/cli:launcher: Run onWorkerStart hook
INFO #wdio/local-runner: Start worker 0-0 with arg: run,wdio.conf.js
INFO #wdio/local-runner: Run worker command: run
...
INFO devtools:puppeteer: Initiate new session using the DevTools protocol
ERROR #wdio/runner: Error: Couldn't find executable for browser
...
INFO #wdio/cli:launcher: Run onComplete hook
I've tried different combinations of options with 'wdio:devtoolsOptions' and 'moz:firefoxOptions'.
Plus checked whether could help dumpio: true, and 'moz:debuggerAddress': true options.
Also I've tried substitution browserName with product and adding binary and executablePath to capabilities.
When passing binary: 'path.to.firefox' to 'moz:firefoxOptions' options, the error message changes to:
ERROR #wdio/runner: Error: Only Nightly release channel is supported in Devtools/Puppeteer for Firefox. Refer to the following issue:
...
Any ideas how it could be fixed in webdriverIO (without installing separately puppeteer or puppeteer-firefox)?
Thanks!
Seems that I took desired for real.
wdio + devtools:puppeteer still work with Firefox Nightly only – https://github.com/webdriverio/webdriverio/discussions/7916
While running automation tests I sometimes get a timeout error for Selenium Webdriver (I think this is where the issue is at least). Me and my team have all recently migrated to Macbooks (from a combination of Windows and Ubunutu machines) and are all getting this behaviour.
While running a suite of tests I will (seemingly at random) get the following error output in the console:
Errno::ETIMEDOUT: Failed to open TCP connection to 127.0.0.1:9515 (Operation timed out - connect(2) for "127.0.0.1" port 9515)
This doesn't happen consistently, sometimes I'll run a pack and not have any such errors, sometimes I'll have multiple occurrences.
Here is the code which registers the driver (in case anything here points to what the issue could be):
Capybara.register_driver :selenium do |app|
opts = Selenium::WebDriver::Chrome::Options.new
opts.add_argument '--start-maximized'
opts.add_argument 'disable-infobars'
opts.add_argument '--disable-notifications'
opts.add_preference(:safebrowsing,
enabled: true)
opts.add_preference(:browser, set_download_behavior: { behavior: 'allow' })
Capybara::Selenium::Driver.new(app, browser: :chrome, options: opts)
end
The gems I am using are Capybara (3.11.0), Cucumber (3.1.0) and Selenium-webdriver (3.141.0). I have ChromeDriver(73.0.3683.68) installed via HomeBrew
Has anyone encountered this issue and worked out what the cause is?
Port 9515 is the default port chromedriver runs on. If you happen to be using Chrome/chromedriver v74 try rolling back to 73 or forward to 75 - 74 has been reported to have issues where it will randomly hang.
Another potential solution is to upgrade to Capybara >= 3.16.0 which defaults to using a persistent connection to chromedriver. This would mean less opening/closing of connections and less chance for chromedriver to hang during connection establishment.
I am using Capybara Selenium to run headless Chrome, which works great, except I cannot figure out how to use remote debugging. When I add --remote-debugging-port=4444 or --remote-debugging-port=9222 or --remote-debugging-port=9521, Selenium no longer connects to the browser to run the test.
How do I get remote debugging to work? Here is my code for reference:
Capybara.register_driver :selenium do |app|
# from https://github.com/SeleniumHQ/selenium/issues/3738
capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(loggingPrefs: {browser: 'ALL'})
options = Selenium::WebDriver::Chrome::Options.new
options.add_argument '--disable-infobars' # hide info bar about chrome automating test
# if we don't use this flag, every selenium test will die with the error:
# "unknown error: Chrome failed to start: exited abnormally"
options.add_argument '--no-sandbox'
# BREAKS THINGS if uncommented
# options.add_argument '--remote-debugging-port=4444'
options.add_argument '--headless'
options.add_argument '--window-size=1600,2400'
options.add_preference('profile.default_content_settings.popups', 0)
options.add_preference('download.default_directory', DownloadHelpers::PATH.to_s)
Capybara::Selenium::Driver.new(
app,
clear_local_storage: true,
clear_session_storage: true,
browser: :chrome,
options: options,
desired_capabilities: capabilities,
)
end
Since chrome 67 and chromedriver 2.39, chromedriver now correctly uses the port you specify with --remote-debugging-port. This removes quite a bit of complexity from my answer above. The steps I now take, which work for my use case of needing to configure download settings using chrome_remote, are as follows:
It makes uses of a nodejs library, crmux - which allows multiple clients to connect to the remote debug port of chrome at the same time.
Get nodejs installed first: Nodejs v9.7.0 works fine
Install crmux by running npm install crmux -g
Before you start chromedriver (Capybara::Selenium::Driver.new), you need to spawn a separate thread that will fire up crmux, which will let both you and chromedriver communicate with chrome itself via the port you specified in Capybara (4444):
crmux --port=4444 --listen=4444
You may want to add a sleep 3 after the spawn command in the main script/thread to give time for crmux to start before you continue with your test startup.
You can then use chrome_remote (for example) to access chrome using port 4444, while capybara is doing its thing.
Updating my ChromeDriver fixed it for me. I didn't have to do anything else. Before it would hang when attempting to start the test.
Specifically I was on ChromeDriver 2.36 and I upgraded to ChromeDriver 2.40. I don't think the Chrome version was a problem, since I was on Chrome 67 both before and after.
Here's how I'm registering the driver:
Capybara.register_driver :headless_chrome do |app|
capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
chromeOptions: { args: %w[headless window-size=1280,960 remote-debugging-port=9222] }
)
Capybara::Selenium::Driver.new(app, browser: :chrome, desired_capabilities: capabilities)
end
After that I ran my test with a debugger (binding.pry) placed where I wanted to inspect. Then when I hit the debugger I navigated to http://localhost:9222/ in a normal instance of Chrome and was able to follow a link to view what was happening in the headless Chrome instance, including the browser console output I needed.
Update: if using versions since Chrome 67/chromedriver 2.39, my alternative answer above provides a simpler solution
The core issue here is Chromedriver also uses the remote debugging port connection to communicate with Chrome. This uses the websocket protocol, which only supports a single-client connected at a time. Normally, when chromedriver starts the chromedriver process, it will choose a random free TCP port number and use this to access the remote debug port. If you specify --remote-debuggging-port=9222 however, Chrome will be opened with the debug port you have requested, but chromedriver will silently continue to try and open a connection using this random port number.
The solution I ended up with was heavily inspired by comment 20 in this chromedriver issue. It required quite a bit of code to get it working, but works solidly. It makes uses of a nodejs library, crmux - which allows multiple clients to connect to the remote debug port of chrome at the same time.
Get nodejs installed first: Nodejs v9.7.0 works fine
Install crmux by running npm install crmux -g
Before you start chromedriver (Capybara::Selenium::Driver.new), you need to spawn a separate thread that will do a few things: look for the remote debug port chromedriver is trying to use to connect to chrome, and then use this to fire up crmux. Once this has happened Capybara etc will work as normal.
My separate thread runs a ruby script that first executes a netstat command repeatedly until it finds the relevant entry for chromedriver (TCP status is SYN_SENT). This separate thread must continue to run in the background while chrome is up and running.
The code for this is:
$chrdrv_wait_timeout = 60
$chrdrv_exe = "chromedriver.exe"
def get_netstat_output
stdout = `netstat -a -b -n`
stat_lines = stdout.split("\n")
stat_lines
end
def try_get_requested_port
socket_state = "SYN_SENT" # i.e. sent with no reply
statout = get_netstat_output
n = statout.length
i = 0
loop do
i += 1
# find lines relating to chromedriver
exe_match = /^ +\[#{$chrdrv_exe}\]$/.match statout[i]
if exe_match != nil
# check preceeding lines which should contain port info
port_match = /TCP.*:([0-9]+)\W+#{socket_state}/.match statout[i-1]
if port_match != nil
return port_match[1].to_i
end
end
break unless i < n
end
return nil
end
def get_tcp_port_requested_by_chromedriver
i = 1
loop do
puts "Waiting for #{$chrdrv_exe}: #{i}"
port = try_get_requested_port
if port != nil
return port
end
break unless i < $chrdrv_wait_timeout
sleep 1
i += 1
end
raise Exception, "Failed to get TCP port requested by #{$chrdrv_exe} (gave up after #{$chrdrv_wait_timeout} seconds)"
end
(I'm working in Windows: for Mac/Linux the netstat syntax/output is probably different so the code will need adjustment; the key thing is you need it to output the executable owner of each connection entry - and parse the bit relating to chromedriver to get the port in question).
Once this has found the random port (I'll use 12225 as an example), the background ruby script can then execute a crmux process, which will reunite chromedriver with chrome itself via the port you specified in Capybara (4444):
crmux --port=4444 --listen=12225
Finally, this separate script saves the discovered listen port to a text file. This allows the main script/thread that is running capybara to know the port number it can use to get access to chrome (via crmux's multiplexed connection) by reading in the port from that file. So you can then use chrome_remote to access chrome using port 12225, for example, while capybara is doing its thing.
I am experiencing issue with Phantomjs headless automation testing on linux. We are using Jenkins as our CI server. However, we are getting the error below:
phantomjs://platform/console++.js:263 in error
[ERROR - 2016-12-09T19:45:12.372Z] WebElementLocator -
_handleLocateCommand - Element(s) NOT Found: GAVE UP.
Search Stop Time: 1481312712354
phantomjs://platform/console++.js:263 in error
How we start phantomjs:
phantomjs --webdriver=8001
Environment:
Phantomjs: 2.1.1
Jenkins: 1.598
Linux: Linux xxx1247 2.6.32-573.12.1.el6.x86_64
Ruby: 1.9.3
Cucumber: 2.1.4
Selenium-webdriver: 2.53
Please share your solution. Thanks!
There can be a few causes for this. One of them can be that the get action to the Web URL failed. That means you are operating on an empty result, which will throw that error.
Since the webpage is not fetched, the element will not be there.
Travis installs Firefox 31.0esr by default, but we want to always use the latest version. The reference here says it should be pretty straight forward, but it doesn't seem to actually install, rather it just seems to download the tar file. Protractor still uses Firefox version 31.0esr when it runs.
travis.yml
addons:
firefox: "latest"
protractor.conf.js
capabilities: {
'browserName': 'firefox'
}
Logs:
Initial Firefox install still happens:
[34m[1mInstalled Firefox version[0m
firefox 31.0esr
... the addon section kicks in and downloads the file fine, before the before_install section as expected:
[0Ktravis_fold:start:install_firefox
[0K$ export FIREFOX_SOURCE_URL='https://download.mozilla.org/?product=firefox-latest&lang=en-US&os=linux64'
[33;1mInstalling Firefox latest[0m
travis_time:start:0dff0345
[0K$ wget -O /tmp/firefox-latest.tar.bz2 $FIREFOX_SOURCE_URL
--2016-01-04 23:29:18-- https://download.mozilla.org/?product=firefox-latest&lang=en-US&os=linux64
Resolving download.mozilla.org (download.mozilla.org)... 52.20.26.65
Connecting to download.mozilla.org (download.mozilla.org)|52.20.26.65|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://download.cdn.mozilla.net/pub/firefox/releases/43.0.3/linux-x86_64/en-US/firefox-43.0.3.tar.bz2 [following]
--2016-01-04 23:29:18-- http://download.cdn.mozilla.net/pub/firefox/releases/43.0.3/linux-x86_64/en-US/firefox-43.0.3.tar.bz2
Resolving download.cdn.mozilla.net (download.cdn.mozilla.net)... 23.0.160.35, 23.0.160.65
Connecting to download.cdn.mozilla.net (download.cdn.mozilla.net)|23.0.160.35|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 52525181 (50M) [application/x-bzip2]
Saving to: `/tmp/firefox-latest.tar.bz2'
0% [ ] 0 --.-K/s
33% [============> ] 17,618,150 84.0M/s
67% [=========================> ] 35,556,926 84.7M/s
100%[======================================>] 52,525,181 83.6M/s in 0.6s
2016-01-04 23:29:18 (83.6 MB/s) - `/tmp/firefox-latest.tar.bz2' saved [52525181/52525181]
travis_time:end:0dff0345:start=1451950158289192377,finish=1451950158979104185,duration=689911808
[0Ktravis_fold:end:install_firefox
... then when protractor starts:
[launcher] Running 1 instances of WebDriver
Selenium standalone server started at http://172.17.1.120:39697/wd/hub
Browser details:
Platform: LINUX
Browser Name: firefox
Browser Version: 31.0
I have a sneaking suspicion that even though the Travis docs says the addon section installs the file too, there is no indication this actually happens so I don't think it does.
For interests sake, this is how we print out the system information when protractor starts:
this.getBrowserCapabilities = function() {
return browser.getCapabilities().then(function (s) {
var browserCapabilities = {
browserName: '',
browserVersion: '',
platform: ''
};
browserCapabilities.platform = s.caps_.platform;
browserCapabilities.browserName = s.caps_.browserName;
browserCapabilities.browserVersion = s.caps_.version;
return browserCapabilities;
});
};
I stumbled over the same issue myself and I can confirm that Travis only downloads the specified firefox version.
This is what I did in my build script to use the downloaded version (in my example 43.0).
First, configure the addon in your .travis.yml file:
addons:
firefox: "43.0"
Now before runing your tests execute these steps:
echo "Extracting firefox and setting PATH variable..."
tar -xjf /tmp/firefox-43.0.tar.bz2 --directory /tmp
export PATH="/tmp/firefox:$PATH"
echo "Using firefox version `firefox --version`"
For a working example see also:
https://github.com/astehlik/typo3-extension-news_richteaser/blob/master/.travis.yml
I'm using Selenium in my case but I guess it should work no different with protractor.