We Keep Coding

Docker/Selenium/Headless Chrome: Configure SUID sandbox correctly

I want to run selenium and headless chrome in my docker container for testing purpose.
I have tried to run selenium in headless chrome (outside my docker container) with the following in my .js file. This worked:
const client = webdriverio.remote({
desiredCapabilities: {
browserName: 'chrome',
chromeOptions: {
args: ['--headless', '--disable-gpu']
},
binary: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
},
baseUrl: CONFIG.host,
logLevel: 'verbose',
waitForTimeout: 3000
})
But I can't get this to work in my docker container. In my docker container I use "FROM selenium/standalone-chrome". There does not seem to be any problem with my dockerfile. The problem occurs when I try to run my selenium tests. I changed the binary_path in my .js file to /opt/google/chrome/google-chrome. But the tests fails and client can not even be initiated.
So I tried to just run /opt/google/chrome/google-chrome in order to see if chrome works, but then I get this error:
[0711/005304.226472:ERROR:nacl_helper_linux.cc(311)] NaCl helper
process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly
I am pretty new to this (and stack overflow) so there might be some basic things I have missed.

Try to include --no-sandbox
chromeOptions: {
args: ['--headless', '--disable-gpu', '--no-sandbox']
},
As I'm doing at docker-selenium

This error message...
[1003/144118.702053:ERROR:nacl_helper_linux.cc(310)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly
...implies that you have no setuid sandbox in your system, hence the program was unable to initiate/spawn a new Browsing Context i.e. Chrome Browser session.
Solution
The easiest (not so clean) solution is, if you want to run Chrome and only use the namespace sandbox, you can set the flag:
--disable-setuid-sandbox
This flag will disable the setuid sandbox (Linux only). But if you do so on a host without appropriate kernel support for the namespace sandbox, Chrome will not spin up. As an alternative you can also use the flag:
--no-sandbox
This flag will disable the sandbox for all process types that are normally sandboxed.
Example:
chromeOptions: {
args: ['--disable-setuid-sandbox', '--no-sandbox']
},
You can find a detailed discussion in Security Considerations - ChromeDriver - Webdriver for Chrome
Deep dive
As per the documentation in Linux SUID Sandbox Development google-chrome needs a SUID helper binary to turn on the sandbox on Linux. In majority of the cases you can install the proper sandbox for you using the command:
build/update-linux-sandbox.sh
This program will install the proper sandbox for you in /usr/local/sbin and tell you to update your .bashrc if required.
However, there can be some exceptions as an example, if your setuid binary is out of date, you will get messages such as:
NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly
Or
Running without the SUID sandbox!
In these cases, you need to:
Build chrome_sandbox whenever you build chrome (ninja -C xxx chrome chrome_sandbox instead of ninja -C xxx chrome)
After building, execute update-linux-sandbox.sh.
# needed if you build on NFS!
sudo cp out/Debug/chrome_sandbox /usr/local/sbin/chrome-devel-sandbox
sudo chown root:root /usr/local/sbin/chrome-devel-sandbox
sudo chmod 4755 /usr/local/sbin/chrome-devel-sandbox
Finally, you have to include the following line in your ~/.bashrc (or .zshenv):
export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox

Chrome Driver Hangs intermittently while execution

I'm using protractor to automate my application, i have around 400 test cases to be automated, i use jenkins for Continous Integration.
Every day i trigger execution through Jenkins as part of nightly executions, but after some time Chrome Driver Hangs, i cant see the browser. But in console log in Jenkins i can see
"[launcher] 1 instance(s) of WebDriver still running" , i cant see browser and my execution can't proceed further and i had to forcefully stop the Build.
I'm using
Windows 7
Protractor 2.5.1
my sample conf.js file
framework: 'jasmine',
jasmineNodeOpts: {
onComplete: null,
defaultTimeoutInterval: 120000,
},
'autoStartStopServer': true,
capabilities: {
'browserName': 'chrome',
shardTestFiles: true,
maxInstances: 1
},
suites: {
specs: '../specs/module1/*.js',
},
I found similar issue with a proposed solution here and here it says to add DBUS_SESSION_BUS_ADDRESS=/dev/null but how to use the same in Windows, any help is appreciated.

In command promt (not git bash or cywin) try this command:
SET DBUS_SESSION_BUS_ADDRESS=/dev/null
To set Environment Variables then run node app, try this command:
SET DBUS_SESSION_BUS_ADDRESS=/dev/null&& node app.js

Running Protractor against a nightly Firefox build

When I try to run Protractor tests against a "Nightly" Firefox build, firefox window hangs indefinitely:
Here is the relevant part of my configuration:
exports.config = {
baseUrl: 'http://localhost:8080/dev/src/',
specs: ['dev/test/e2e/**/dashboard.spec.js'],
directConnect: true,
capabilities: {
browserName: "firefox",
firefox_binary: "/Applications/FirefoxNightly.app/Contents/MacOS/firefox-bin",
},
allScriptsTimeout: 110000,
getPageTimeout: 100000,
framework: 'jasmine2',
jasmineNodeOpts: {
isVerbose: false,
showColors: true,
includeStackTrace: false,
defaultTimeoutInterval: 400000
},
};
There was a related issue with no solution provided.
One of the possible workarounds I've found might be to move the WebDriver xpi extension from the stable firefox installation (or a different source) to the "extensions" directory of the Nightly firefox profile, but I'm not sure how to do it.
I've also found something about using "Marionette" driver to test a nightly Firefox build, but I haven't found any guidelines on it's relationship to Protractor.
Using:
currently latest Protractor 3.0.0
Firefox Nightly is 46.0.a1
Mac OS X El Capitan
Tried with directConnect and without - same behavior.

On both Mac and Linux I had to update to FF 47.0.1 selenium 2.53.1.
I initially explored trying to configure Protractor with the new Mozilla Marionette driver, per the answer by jrharshath
I got protractor to use it (description of what I did below). However, I had manifold problems with the driver running my tests.
I then found discussions saying 47.0.1 and selenium 2.53.1 restored FirefoxDriver functionality, so abandoned the Marionette driver in favor of compatible upgrades.
For those looking at configuring and using the Marionette driver with Protractor and webdriver I did the following:
Downloaded and unzipped the latest Marionette driver from https://github.com/mozilla/geckodriver/releases
Renamed it to wires and put it on the path
Started a standalone selenium webdriver 2.53.1 with the -Dwebdriver.gecko.driver=${path_to_driver} property, and used that server.
Set marionette true in my firefox capabilities in my config, ie :
multiCapabilities:[
{
'browserName': 'chrome'
}
},
{
'browserName': 'firefox',
'marionette' : true
}
],

Apparently this is an issue with Firefox 46. The default FirefoxDriver no longer works with this version - you need to be using the Marionette driver. I also found a quick how-to on using the new driver with Selenium.
I'm facing the same problem as well. We run our tests with directConnect by default, so I'm yet to figure out how to get protractor to use Marionette instead of FirefoxDriver.
If you're having protractor connect to Selenium, then you should be able to follow the guides available to make Selenium use the new driver - that shouldn't affect protractor's relationship with Selenium.
Update: Looking into the problem of using the latest versions of Firefox with directConnect, I found no way of instructing protractor to use the Marionette driver. I've opened an issue with the protractor team for this.

What is a good headless browser to run with protractor?

New User here.
After hours of building my smoke and regression tests, I found out after reading many cases online that phantomjs is known to be a trouble to run with protractor. Jenkins has been running phantomjs for all the tasks it has been given so far.
They need these tests to run as part of ci which does not have a windowing system installed.
So I would appreciate it if there is a recommendation for completely headless browser or a headless chrome(that would be most beneficial) and a step by step to set it up. I already have a conf.js and a e2e.conf.js file. My code works perfectly fine with chrome.
I am on a iMac and selenium webdriver, I believe.
Edit: Problem = protractor doesn't work with phantomjs.
What I have done = use different web elements and googled if anyone has faced a similar situation. Also googled for headless browsers that worked for protractor, unable to find a suitable solution.

If anyone reached here - the answers are outdated.
Chromium (on next release) now supports headless mode. no need to work hard.
You can read more here:
https://developers.google.com/web/updates/2017/04/headless-chrome
Here is an example from command line
chrome \
--headless \ # Runs Chrome in headless mode.
--disable-gpu \ # Temporarily needed for now.
--remote-debugging-port=9222 \
https://www.chromestatus.com # URL to open. Defaults to about:blank.
And you can simply trigger protractor with capabilities for chrome:
Activating chrome language flags when activating from protractor (selenium)
Here is the configuraiton I am using
capabilities: {
'browserName': browserName,
chromeOptions: {
binary: '/Users/guymograbi/Downloads/chrome-mac/Chromium.app/Contents/MacOS/Chromium',
args: ['--headless','--disable-gpu']
}
},
Update - new versions of chrome doesn't require binary property
In my environments I found I can remove the binary property as new version of chrome is available on stable branches
My protractor configuration is
capabilities: {
'browserName': 'chrome',
chromeOptions: {
args: [ '--headless', '--disable-gpu', '--no-sandbox', '--window-size=1920x1200' ]
},
},
And it works smoothly for weeks now. highly recommended.
Update - how to do this in karma is super easy
Using headless chrome in karma is super easy:
browsers: 'ChromeHeadless'
it should work with the chrome loader and everything. more info

Your best bet is to continue with Chrome. With a bit of work you can get it to work via a CI and in a headless manner - we do this using Jenkins and Docker Ubuntu servers which are headless.
You will need to configure Chrome to run headless using XVFB. You can start off by following the gist here https://gist.github.com/addyosmani/5336747
You state you are on a Mac so you can either run the headless tests via Docker on your machine or you could set up a second config for the CI tests.
Another resource http://tobyho.com/2015/01/09/headless-browser-testing-xvfb/

I would continue testing in normal browsers with a head, but would use a remote selenium server as a service - Sauce Labs or BrowserStack, see:
Integration Testing with Protractor, WebdriverJS and Sauce Labs
Running Protractor tests on Browserstack Automate
automate-node-samples

You could run your Protractor tests against CodeShip or Drone.io, both of which offer Chrome and/or Firefox running headless for free. No really...

If you've got Chrome 59+ installed, start Chrome with the following flag:
--headless
please let me know if you need more help, will write the config for you :) enjoy

Karma/Jasmine times out without running tests

I'm trying to run Karma/Jasmine from Grunt on a project generated with
http://newtriks.com/2013/12/31/automating-react-with-yeoman-and-grunt/
Karma launches PhantomJS (or Chrome) and, depending on singleRun, it either times out or just sits there and does nothing. I've tried changing captureTimeout and browserNoActivityTimeout based on reading solutions from people with similar problems, but it doesn't seem to work.
My relevant pacakge versions etc.:
NodeJS: 0.10.25
Karma: 0.12.16
Webpack: 1.1.11
webpack-dev-server: 1.4.1
karma-jasmine: 0.1.5
Linux: Ubuntu 14.04
I've found someone with the same problem on OS X:
I've tried updating all my dev dependencies to the latest versions but the problem still remains.
My console output is below. The webpack lines referring to bundle is now VALID/INVALID are worrying, but I can't find any info on what they mean. Here's my console output:
Running "karma:unit" (karma) task
DEBUG [config]: autoWatch set to false, because of singleRun
DEBUG [plugin]: Loading karma-* from /home/ed/workspace/wwb-app/node_modules
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-chrome-launcher.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-coffee-preprocessor.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-firefox-launcher.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-html2js-preprocessor.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-jasmine.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-phantomjs-launcher.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-requirejs.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-script-launcher.
DEBG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-webpack-plugin.
INFO [karma]: Karma v0.12.16 server started at http://localhost:8080/
INFO [launcher]: Starting browser PhantomJS
DEBUG [temp-dir]: Creating temp dir at /tmp/karma-98204612
DEBUG [launcher]: /home/ed/workspace/wwb-app/node_modules/karma-phantomjs-launcher/node_modules/phantomjs/lib/phantom/bin/phantomjs /tmp/karma-98204612/capture.js
Hash: 89285186567c1bc5bb7f
Version: webpack 1.1.11
Time: 2ms
Asset Size Chunks Chunk Names
webpack: bundle is now VALID.
webpack: bundle is now INVALID.
DEBUG [web-server]: serving: /home/ed/workspace/wwb-app/node_modules/karma/static/client.html
DEBUG [web-server]: serving: /home/ed/workspace/wwb-app/node_modules/karma/static/karma.js
DEBUG [web-server]: upgrade /socket.io/1/websocket/CjC8pnQq5It2z_kWYB98
DEBUG [karma]: A browser has connected on socket CjC8pnQq5It2z_kWYB98
INFO [PhantomJS 1.9.7 (Linux)]: Connected on socket CjC8pnQq5It2z_kWYB98 with id 98204612
DEBUG [launcher]: PhantomJS (id 98204612) captured in 1.704 secs
WARN [PhantomJS 1.9.7 (Linux)]: Disconnected (1 times), because no message in 30000 ms.
DEBUG [karma]: Run complete, exitting.
DEBUG [launcher]: Disconnecting all browsers
DEBUG [launcher]: Process PhantomJS exited with code 0
DEBUG [temp-dir]: Cleaning temp dir /tmp/karma-98204612
Warning: Task "karma:unit" failed. Use --force to continue.
Aborted due to warnings.
Here's my karma.conf.js file:
'use strict';
module.exports = function (config) {
config.set({
basePath: '',
frameworks: ['jasmine'],
files: [
'test/helpers/**/*.js',
'test/spec/components/**/*.js'
],
preprocessors: {
'test/spec/components/**/*.js': ['webpack']
},
webpack: {
cache: true,
module: {
loaders: [{
test: /\.css$/,
loader: 'style!css'
}, {
test: /\.gif/,
loader: 'url-loader?limit=10000&minetype=image/gif'
}, {
test: /\.jpg/,
loader: 'url-loader?limit=10000&minetype=image/jpg'
}, {
test: /\.png/,
loader: 'url-loader?limit=10000&minetype=image/png'
}, {
test: /\.js$/,
loader: 'jsx-loader'
}]
}
},
webpackServer: {
stats: {
colors: true
}
},
exclude: [],
port: 8080,
logLevel: config.LOG_DEBUG,
colors: true,
autoWatch: true,
// Start these browsers, currently available:
// - Chrome
// - ChromeCanary
// - Firefox
// - Opera
// - Safari (only Mac)
// - PhantomJS
// - IE (only Windows)
browsers: ['PhantomJS'],
reporters: ['progress'],
captureTimeout: 60000,
browserNoActivityTimeout: 60000,
singleRun: true
});
};

I had the same problem. From a related GitHub Issue, I learned that you can extend the inactivity timeout.
Set this Karma config option in your gruntfile or karma config file:
browserNoActivityTimeout: 100000
I set it to 100 seconds and my tests ran successfully. I don't know what's causing the delay.

I've changed my Karma config, to
captureTimeout: 60000, // it was already there
browserDisconnectTimeout : 10000,
browserDisconnectTolerance : 1,
browserNoActivityTimeout : 60000,//by default 10000
Also I have 200-300 tests, PhantomJS 1.9.8
and it needs only about 100 mb memory for Phantom
With grunt and karma
They all together used about 300mb of memory.

We encountered a similar problem on our build servers.
Increasing the browserNoActivityTimeout worked to a point. We upped it to 60000ms, but the problem with phantomJS not disconnecting returned as the number of unit tests increasing.
We eventually tracked the problem down to the RAM available to phantomJS. We had 1100 unit tests that would take ~1m30s to run, but phantomJS would fail to disconnect within the 60000ms timeout.
The build node VM RAM was increased from 2GB to 4GB and the 1100 unit tests then took ~45s to run and phantomJS would disconnect with ~5s. A huge improvement.
There are two lessons:
1. PhantomJS is memory hungry, so make sure it has enough RAM to do its thing
2. Profile your code to learn where you can be more efficient with memory usage.

Another likely explanation is RequireJS getting in the way. I'm getting this exact error if I add 'requirejs' to the karma.conf.js in the config.frameworks array.
This seems to override the native require function and cause tests to not be executed. In my case the describe-block was triggered, but none if the it-blocks were.

In my case I hadn't included the following code in my test.js file:
requirejs.config({
callback: window.__karma__.start
});
describe('tests', function() {
...
Once this config was included the tests started running. Hopefully this saves someone else a lot of stress!

Remove the 'requires' from the karma config file, just use frameworks: ['jasmine'].

Check that localhost points correctly to 127.0.0.1 and not an unreachable IP, this can happen in dev environments using virtual machines for example.

This may not be the case for the OP here, but if the code you're testing hits an infinite loop, it will cause a disconnection on timeout just like this.

Here is why I was getting this error, might help someone in similar situation.
My main component had multiple child components which were using different services, one of the services had an HTTP call and the initialisation failed as I was using that service in ngInit() method of the child component.
To fix the issue, I had to import the above service in the main component specs and attach a mock for the service, it started working after that.

I solved this for my own environment. I had a bunch of nodejs packages installed globally. I didn't do a regression to figure out exactly what package caused the problem, but I strongly suspect that having karma installed globally was the cause.
If you have this problem then try
sudo npm -g remove karma
and if that doesn't work then I would remove all global node packages (except truly global packages like yeoman, grunt-cli, for example). And then install locally for your project.
I also noticed that when you run sudo npm -i on OS X, it changes the owner of ~/.npm to root and subsequent npm -i commands will fail with an EACCESS error,.

#Vijender's answer got me on the right track
It was as simple as replacing HttpClientModule in tests with HttpClientTestingModule.
beforeEach(async(() => {
TestBed.configureTestingModule({
imports: [
HttpClientTestingModule
]
}).compileComponents();
}));

I fixed this by removing a call to an async function at global scope, in my Root.tsx.
It was working in a 'real' browser window, but doesn't work in a test run.
It seems to make loading the module itself hang, so it doesn't even get as far as executing the async function (so log statements won't show up)
Edit:
This was caused by another async function, run at app startup, that was trying to do auth and redirect to another URL. That's why it worked in the browser but not in headless mode. Without any async test functions, the auth code never had a chance to jam the system. With an async test, the async auth code started running and caused the lock-up.
Moral of the story: if an async test is hanging, check what other async code is going on in the background.

afterEach(function () {
document.body.innerHTML = '';
});
Adding this fixed issue for me, tests started running much faster. Seems like it decreases load on headless browser.