theintern / digdug Goto Github PK

Description
SeleniumTunnel fails to download ChromeDriver for versions 2.23+ on Mac OS X. The root cause seems to be that for ChromeDriver versions 2.23+, the downloadable is named "chromedriver_mac64.zip" instead of "chromedriver_mac32.zip", which was the case for all previous versions.

Steps to Reproduce
digdug: 1.5.0
Node: 4.1.1
OS: Mac OS X El Capitan (10.11.6)

• Start the Intern test runner, passing in a config object that includes the following:

{ environments: [{browserName: "chrome"}], tunnel: "SeleniumTunnel", tunnelOptions: { version: "2.53.1", drivers: [ { name: "chrome", version: "2.24", }, ], }, ... }

• The chromedriver executable is not downloaded to the digdug/selenium-standalone directory and an exception is thrown (see below).

Expected Result
SeleniumTunnel downloads ChromeDriver executable for version 2.23+ and starts the tunnel as normal.

Actual Result
The executable is not downloaded and the tunnel fails to start. Here's a sample stack trace:

Listening on 0.0.0.0:9000 Tunnel started Suite chrome on any platform FAILED UnknownError: [POST http://localhost:4444/wd/hub/session / {"desiredCapabilities":{"name":"test/functional/intern-config","idle-timeout":60,"browserName":"chrome"}}] The driver executable does not exist: /Users/bpartridge/forward/fwd/web/src/main/resources/web/node_modules/intern/node_modules/digdug/selenium-standalone/chromedriver at Server.createSession <node_modules/intern/node_modules/leadfoot/Server.js:330:15> at <node_modules/intern/lib/executors/Runner.js:200:23> at retry <node_modules/intern/lib/util.js:804:13> at <node_modules/intern/node_modules/dojo/Promise.ts:393:15> at runCallbacks <node_modules/intern/node_modules/dojo/Promise.ts:11:11> at <node_modules/intern/node_modules/dojo/Promise.ts:317:4> at run <node_modules/intern/node_modules/dojo/Promise.ts:237:7> at <node_modules/intern/node_modules/dojo/nextTick.ts:44:3> at doNTCallback0 <node.js:407:9> at process._tickCallback <node.js:336:13>

I'd be happy to submit a PR for this if that would help.

I've noticed after my functional tests finish, the browser closes, but chromedriver.exe stays running, leading to multiple instances of chromedriver piling up. The tunnel emits the stopped status and in my console i see "Stopped", so it doesn't seem to be an issue of the tunnel not stopping. I am using selenium tunnel with the following config:

{
    "functionalSuites": "tests/functional/*.js",
    "environments": [
        {
            "browserName": "chrome"
        }
    ],
    "reporters": [{"name": "junit", "filename": "report.xml"}, "runner"],
    "tunnelOptions": {
        "version": "3.8.1",
        "drivers": [
            {
                "name": "chrome"
            }
        ]
    }
}

I was able to get chromedriver.exe to exit by changing

childProcess.kill('SIGINT')

in ./node_modules/@theintern/digdug/Tunnel.js to

setTimeout(function() {
	childProcess.kill('SIGINT');
}, 100);

So, by waiting for 1/10 of a second before killing java.exe, chromedriver.exe actually gets killed. I'm not sure if this is a problem with your codebase or my configuration, which is very minimal. Any help is greatly appreciated.

Intern Version: 4.1.5
Selenium-Server-Standalone-Jar Version: 3.8.1
Chromedriver Version: 2.35
OS: Windows 7
Browser: Chrome Stable (v63)

Both chromedriver.exe and selenium-server-standalone-3.8.1.jar are in ./node_modules/@theintern/digdug/selenium-standalone

When I start Intern with e.g. the BrowserStack tunnel and I use ctrl-c to stop Intern, then the tunnel processes are cleaned up properly, but the node process itself stays running.

I'm not able to instal intern 2.1 due this issue.

http 304 https://registry.npmjs.org/get-stdin
http 304 https://registry.npmjs.org/nopt
http 304 https://registry.npmjs.org/rimraf
http 304 https://registry.npmjs.org/mkdirp
http 304 https://registry.npmjs.org/tar
http 304 https://registry.npmjs.org/stream-combiner
http 304 https://registry.npmjs.org/tempfile
http 304 https://registry.npmjs.org/adm-zip
http 304 https://registry.npmjs.org/map-key
npm ERR! Error: version not found: [email protected]
npm ERR!     at setData (/usr/local/lib/node_modules/npm/lib/cache/add-named.js:127:12)
npm ERR!     at saved (/usr/local/lib/node_modules/npm/node_modules/npm-registry-client/lib/get.js:167:7)
npm ERR!     at /usr/local/lib/node_modules/npm/node_modules/cmd-shim/node_modules/graceful-fs/polyfills.js:133:7
npm ERR!     at Object.oncomplete (fs.js:107:15)
npm ERR! If you need help, you may report this *entire* log,
npm ERR! including the npm and node versions, at:
npm ERR!     <http://github.com/npm/npm/issues>

Using SeleniumTunnel requires a JDK to be available in the environment though there is no mention of this in the DigDug documentation and no graceful checks for this when installing the package. There should be some way of handling this gracefully and documenting the requirement.

References dojo/cli-test-intern#51

Running tests locally (on OSX) in Chrome works fine

config.tunnel = 'SeleniumTunnel';
config.tunnelOptions = {
  drivers: ['chrome'],
};
config.environments = [
  { browserName: 'chrome' },
];

But running tests locally (on OSX) in Firefox does not

config.tunnel = 'SeleniumTunnel';
config.tunnelOptions = {
  drivers: ['firefox'],
};
config.environments = [
  { browserName: 'firefox' },
];

I see a few attempts at opening a Firefox browser window and the terminal shows the following output:

➜  ./node_modules/.bin/intern-runner config=test/firefox
Listening on 0.0.0.0:9000
Tunnel started
Suite firefox on any platform FAILED
UnknownError: [POST http://localhost:4444/wd/hub/session / {"desiredCapabilities":{"name":"test/firefox","idle-timeout":60,"browserName":"firefox"}}] Connection refused
  at Server.createSession  <node_modules/intern/node_modules/leadfoot/Server.js:324:15>
  at <node_modules/intern/lib/executors/Runner.js:200:23>
  at retry  <node_modules/intern/lib/util.js:804:13>
  at <node_modules/intern/node_modules/dojo/Promise.ts:393:15>
  at runCallbacks  <node_modules/intern/node_modules/dojo/Promise.ts:11:11>
  at <node_modules/intern/node_modules/dojo/Promise.ts:317:4>
  at run  <node_modules/intern/node_modules/dojo/Promise.ts:237:7>
  at <node_modules/intern/node_modules/dojo/nextTick.ts:44:3>
  at nextTickCallbackWith0Args  <node.js:420:9>
  at process._tickCallback  <node.js:349:13>

TOTAL: tested 0 platforms, 0/0 tests failed; fatal error occurred
Error: Run failed due to one or more suite errors
  at emitLocalCoverage  <node_modules/intern/lib/executors/Executor.js:353:18>
  at finishSuite  <node_modules/intern/lib/executors/Executor.js:370:15>
  at <node_modules/intern/lib/executors/Executor.js:378:8>
  at <node_modules/intern/browser_modules/dojo/Promise.ts:393:15>
  at runCallbacks  <node_modules/intern/browser_modules/dojo/Promise.ts:11:11>
  at <node_modules/intern/browser_modules/dojo/Promise.ts:317:4>
  at run  <node_modules/intern/browser_modules/dojo/Promise.ts:237:7>
  at <node_modules/intern/browser_modules/dojo/nextTick.ts:44:3>
  at nextTickCallbackWith0Args  <node.js:420:9>
  at process._tickCallback  <node.js:349:13>

What am I missing here?

Currently I am facing a problem, when I use Intern behind a corporate proxy (squid 3). The problem is, as already mentioned in the title, that digdug fails to download Selenium and related Drivers via HTTPS and proxy.

The problem seems to occur in dojo/core's request provider for node, which likely does not establish an HTTP Connect via the proxy.

Excerpt from the proxy's log file caused by Intern:

192.168.81.63 NONE/501 3812 GET https://github.com/mozilla/geckodriver/releases/download/v0.20.1/geckodriver-v0.20.1-linux64.tar.gz - HIER_NONE/- text/html

Update the default webdriver versions in SeleniumTunnel. At least Chrome 72 isn't working with the current chromedriver default.

We have sc running on another machine, I run tests configured like such from my own machine:

tunnel : 'NullTunnel'
tunnelOptions : {
   hostname : 'scserverhost'
}

When I run my tests, I see the following response from SauceLabs

POST /wd/hub/session HTTP/1.1
accept: application/json,text/plain;q=0.9

content-type: application/json;charset=UTF-8

content-length: 113
user-agent: dojo/2.0.0-dev Node.js/0.10.29
Host: scserverhost:4444
Connection: keep-alive

{"desiredCapabilities":{"browserName":"chrome","platform":"Windows 8.1","name":"tests/intern","idle-timeout":60}}HTTP/1.1 401 Unauthorized
Transfer-Encoding: chunked
Date: Wed, 15 Oct 2014 11:09:45 GMT
Content-Type: text/plain
WWW-Authenticate: Basic realm="Sauce OnDemand"
Server: monocle/0.26

123
Sauce Labs Authentication Error.
You used username 'None' and access key 'None' to authenticate, which are not valid Sauce Labs credentials.

The following desired capabilities were received:
{'browserName': 'chrome',
'idle-timeout': 60,
'name': 'tests/intern',
'platform': 'Windows 8.1'}
0

I set username/accessKey environment variables when running node node_modules/intern/runner.js & even tried adding them to tunnelOptions but obviously the NullTunnel doesn't have those properties or deal with them.

Is this a bug or am I missing some other configuration?

Hello,

I am have some tests written with intern in my npm project that I could automatically run using intern command.
But lately, I cannot run them anymore because the following error is logged:

SessionNotCreatedException: [POST http://localhost:4444/wd/hub/session / {"desiredCapabilities":{"name":"intern","idle-timeout":60,"browserName":"chrome","chromeOptions":{"args":["headless","window-size=1024,768"]}}}] session not created: This version of ChromeDriver only supports Chrome version 74
  (Driver info: chromedriver=74.0.3729.6 (255758eccf3d244491b8a1317aa76e1ce10d57e9-refs/branch-heads/3729@{#29}),platform=Windows NT 10.0.16299 x86_64) (WARNING: The server did not provide any stacktrace information)

My intern.json file looks like the following:

{
  "capabilities": {
    "fixSessionCapabilities": "no-detect"
  },
  "environments": [
    {
      "browserName": "chrome",
      "chromeOptions": { "args": [ "headless", "window-size=1024,768" ] }
    }
  ],
  "filterErrorStack": true,
  "suites": "~tmp/tests.js"
}

Chrome installed version is "Version 76.0.3809.100 (Build officiel) (64 bits)" on Windows10.

Digging around, I noticed that npm "digdub" package downloaded selenium server standalone-3.141.59.jar and chrome driver 74.0.3729.6.
If I manually edit "SeleniumTunnel.js" file and update ChromeVersion property of object driverInfo to '76.0.3809.68' then it downloads chromedriver 76.0.3809.68 and my tests are executed :

So I wonder why is version 74 of chrome hardcoded and how am supposed to do if the version of chrome installed is 76 ?:

Thanks for your help !

I'm sad to see this repository be deprecated. I'd like to continue using it for a little while longer until I have a chance to migrate to something else. Could you upgrade the webdriver versions used to support the latest browsers (specifically Chrome 80) to buy time to migrate off?

Seems like this option is currently only documented in the "on-the-same-machine" section of the Sauce Labs docs.
I will try to send a PR for this tomorrow or when I get time.

Ref: https://github.com/saucelabs/docs/issues/74
Ref: https://docs.saucelabs.com/reference/sauce-connect/#on-the-same-machine

Update SeleniumTunnel to be able to download MicrosoftWebDriver.

As the title says.

Ensure that BrowserStack's new v7 local binary works properly with Dig Dug.

Due to limitations at the time this code was written (no streaming support in the old Dojo request API), it is using the low-level Node.js request API so doesn’t easily support downloading via proxy. Should be updated to use the Dojo 2 Core request API, which supports HTTP proxies.

See theintern/intern#215

Ref: https://docs.saucelabs.com/reference/sauce-connect/#command-line-options

-t, --tunnel-domains <...>      Inverse of '--direct-domains'.
                                Only requests for domains in this 
                                list will be sent through the 
                                tunnel.

I've just received the following mail from BrowserStack support:

We noticed that you are using "http://hub.browserstack.com:4444" while running your Selenium tests on BrowserStack Automate. We would recommend that you switch to either port 80 ("http://hub.browserstack.com:80") or port 443 ("https://hub.browserstack.com:443"), because we will be disabling port 4444 by 5th May, 2016. We are in the process of making modifications which will improve the overall performance of your tests via port 80 and 443.

While it is possible to defer this configuration to user-land (see below), that's not desireable…

{
  tunnel: "BrowserStackTunnel",
  tunnelOptions: {
     hostname: "hub.browserstack.com",
     protocol: "https",
     port: 443
  },
}

It would be good if one can specify latest and previous version for Browserstack tunnel to reference the current and previous versions for the browsers available on browserstack. This feature is available in browserstack-runner as of now: https://github.com/browserstack/browserstack-runner#compact-browsers-configuration

I'm running intern functional tests on Sauce Labs and in our environment the sauce connect is always up and running. I'm able to run tests using NullTunnel.js and specifying "tunnelOptions.clientUrl" (pointing to our sauce connect), but this way the Sauce Labs job status is not being updated. I'm not able to use SauceLabsTunnel.js in this case, because it will complain about sauce connect already running. Is it possible to configure SauceLabsTunnel.js in the way that it will allow for the sauce connect to be already running, and then it would update the Sauce Labs job status? Currently I have written a mixed version of those tunnels and called it "NullSauceTunnel.js" which works for me, but it would be better to have an option to configure it natively.

Below is the code of my "NullSauceTunnel.js":

/**
* @module digdug/NullSauceTunnel
*/

var Promise = require('dojo/Promise');
var Tunnel = require('./Tunnel');
var util = require('./util');
var urlUtil = require('url');
var request = require('request');

function success() {
return Promise.resolve();
}

/**
* A no-op tunnel.
*
* @constructor module:digdug/NullSauceTunnel
* @extends module:digdug/Tunnel
*/
function NullSauceTunnel() {
Tunnel.apply(this, arguments);
}

var _super = Tunnel.prototype;
NullSauceTunnel.prototype = util.mixin(Object.create(_super), /** @lends module:digdug/NullTunnel */ {
auth: '',
isDownloaded: true,
download: success,
start: function () {
this.isRunning = true;
return success();
},
stop: function () {
this.isRunning = false;
return success();
},
sendJobState: function (jobId, data) {

var url = urlUtil.parse(this.restUrl || 'https://saucelabs.com/rest/v1/');
url.auth = this.username + ':' + this.accessKey;
url.pathname += this.username + '/jobs/' + jobId;

payload = JSON.stringify({
build: data.buildId,
'custom-data': data.extra,
name: data.name,
passed: data.success,
public: data.visibility,
tags: data.tags
});

var result = new Promise.Deferred();

request({
body: payload,
headers: {
"accept":"application/json"
},
auth : {
"username" : this.username,
"password" : this.accessKey
},
method : "PUT",
proxy: this.proxy,
url : urlUtil.format(url)

}, function (error, response, body) {
response.data = body;
result.resolve(response);
});

return result.promise.then(function (response) {
if (response.data) {
var data = JSON.parse(response.data);

if (data.error) {
throw new Error(data.error);
}

if (response.statusCode !== 200) {
throw new Error('Server reported ' + response.statusCode + ' with: ' + response.data);
}
}
else {
throw new Error('Server reported ' + response.statusCode + ' with no other data.');
}
});
}
});

module.exports = NullSauceTunnel;

The EdgeConfig class in SeleniumTunnel handles downloading drivers for both EdgeHTML and Edge Chromium. However, these two drivers have different names and are packaged differently. Edge Chromium should have its own config class, or EdgeConfig should use different semantics depending on the version of the driver being used.

Currently, Dig Dug relies on Selenium to manage individual webdrivers. However, many users may not wish to install Java, which is needed to run Selenium. While Dig Dug's NullTunnel can be used to interface with any locally running webdriver, it's not as hands-off as SeleniumTunnel. Consider adding tunnels that can manage chromedriver, geckodriver, etc. directly instead of through Selenium.

When I run npm install on fresh copy of the project at my work and then try to compile it I receive the following error:

node_modules/@theintern/digdug/Tunnel.d.ts:6:22 - error TS2420: Class 'Tunnel' incorrectly implements interface 'Url'.
  Type 'Tunnel' is missing the following properties from type 'Url': hash, host, href, path, and 3 more.

6 export default class Tunnel extends Evented<TunnelEvents, string> implements TunnelProperties, Url {
                       ~~~~~~


Found 1 error.

The only workaround I found is manually add the following properties into Tunnel.d.ts:

    hash: string;
    host: string;
    href: string;
    path: string;
    search: string;
    slashes: boolean;
    query: string;

That is not the correct way of resolving that of course, but I can't find any better. I am new to Typescript, and therefore it is possible that I do something wrong.

Could you please advise?

As part of the ES6/TS refactor, we are migrating Dig Dug to TypeScript.  This issue will cover the conversion and test updates needed.

Be sure to take into consideration work done for the Intern Migration: theintern/intern#674

Chrome 65 started rolling out to users' browsers. In order to support Chrome 65, the code already committed to master needs to be released to npm.

Running a intern locally with null + manual chromedriver or using selenium tunnel works fine
But when I try to run the same intern on Jenkins, it downloads the tunnels (null/ selenium - why does it need to download null tunnel anyway?) and then throws:

Tunnel download: 100.000%
Failed to start tunnel�[K
Stopping�[K
Unhandled error: TypeError: invalid pid
    at process.kill (internal/process.js:168:13)
    at killPid (/deployment/node_modules/tree-kill/index.js:73:17)
    at /deployment/node_modules/tree-kill/index.js:55:17
    at Array.forEach (<anonymous>)

What could cause this?

intern version: 4.2.0

EDIT - I simulated the issue locally. The problem seems to be with the docker which intern runs on.

The fix for #43 in Selenium 3.4.0 no longer works in 3.5..

3.4.0 w/ debug true

java -jar selenium-server-standalone-3.4.0.jar -debug true
13:12:22.755 INFO - Selenium build info: version: '3.4.0', revision: 'unknown'
13:12:22.756 INFO - Launching a standalone Selenium Server
2017-10-03 13:12:22.777:INFO::main: Logging initialized @238ms to org.seleniumhq.jetty9.util.log.StdErrLog
13:12:22.828 INFO - Driver provider org.openqa.selenium.ie.InternetExplorerDriver registration is skipped:
registration capabilities Capabilities [{ensureCleanSession=true, browserName=internet explorer, version=, platform=WINDOWS}] does not match the current platform MAC
13:12:22.828 INFO - Driver provider org.openqa.selenium.edge.EdgeDriver registration is skipped:
registration capabilities Capabilities [{browserName=MicrosoftEdge, version=, platform=WINDOWS}] does not match the current platform MAC
13:12:22.828 INFO - Driver class not found: com.opera.core.systems.OperaDriver
13:12:22.828 INFO - Driver provider com.opera.core.systems.OperaDriver registration is skipped:
Unable to create new instances on this machine.
13:12:22.828 INFO - Driver class not found: com.opera.core.systems.OperaDriver
13:12:22.828 INFO - Driver provider com.opera.core.systems.OperaDriver is not registered
2017-10-03 13:12:22.866:INFO:osjs.Server:main: jetty-9.4.3.v20170317
2017-10-03 13:12:22.902:INFO:osjsh.ContextHandler:main: Started o.s.j.s.ServletContextHandler@14acaea5{/,null,AVAILABLE}
2017-10-03 13:12:22.933:INFO:osjs.AbstractConnector:main: Started ServerConnector@e25b2fe{HTTP/1.1,[http/1.1]}{0.0.0.0:4444}
2017-10-03 13:12:22.933:INFO:osjs.Server:main: Started @395ms
13:12:22.933 INFO - Selenium Server is up and running

3.5.0 w/ debug true

java -jar selenium-server-standalone-3.5.0.jar -debug true
Exception in thread "main" com.beust.jcommander.ParameterException: Was passed main parameter 'true' but no main parameter was definedat com.beust.jcommander.JCommander.getMainParameter(JCommander.java:914)at com.beust.jcommander.JCommander.parseValues(JCommander.java:759)at com.beust.jcommander.JCommander.parse(JCommander.java:282)at com.beust.jcommander.JCommander.parse(JCommander.java:265)at com.beust.jcommander.JCommander.(JCommander.java:210)at org.openqa.grid.selenium.GridLauncherV3$1.setConfiguration(GridLauncherV3.java:227)at org.openqa.grid.selenium.GridLauncherV3.buildLauncher(GridLauncherV3.java:155)at org.openqa.grid.selenium.GridLauncherV3.main(GridLauncherV3.java:75)

3.5.0 w/ debug

java -jar selenium-server-standalone-3.5.0.jar -debug
13:15:59.437 INFO - Selenium build info: version: '3.5.0', revision: '8def36e068'
13:15:59.438 INFO - Launching a standalone Selenium Server
2017-10-03 13:15:59.456:INFO::main: Logging initialized @223ms to org.seleniumhq.jetty9.util.log.StdErrLog
13:15:59.505 INFO - Driver class not found: com.opera.core.systems.OperaDriver
13:15:59.530 INFO - Driver provider class org.openqa.selenium.ie.InternetExplorerDriver registration is skipped:
registration capabilities Capabilities [{ensureCleanSession=true, browserName=internet explorer, version=, platform=WINDOWS}] does not match the current platform MAC
13:15:59.530 INFO - Driver provider class org.openqa.selenium.edge.EdgeDriver registration is skipped:
registration capabilities Capabilities [{browserName=MicrosoftEdge, version=, platform=WINDOWS}] does not match the current platform MAC
13:15:59.558 INFO - Using the passthrough mode handler
2017-10-03 13:15:59.582:INFO:osjs.Server:main: jetty-9.4.5.v20170502
2017-10-03 13:15:59.601:WARN:osjs.SecurityHandler:main: [email protected]@3632be31{/,null,STARTING} has uncovered http methods for path: /
2017-10-03 13:15:59.606:INFO:osjsh.ContextHandler:main: Started o.s.j.s.ServletContextHandler@3632be31{/,null,AVAILABLE}
2017-10-03 13:15:59.634:INFO:osjs.AbstractConnector:main: Started ServerConnector@32709393{HTTP/1.1,[http/1.1]}{0.0.0.0:4444}
2017-10-03 13:15:59.634:INFO:osjs.Server:main: Started @402ms
13:15:59.634 INFO - Selenium Server is up and running

3.6.0 w/ debug

java -jar selenium-server-standalone-3.6.0.jar -debug
13:16:03.228 INFO - Selenium build info: version: '3.6.0', revision: '6fbf3ec767'
13:16:03.229 INFO - Launching a standalone Selenium Server
2017-10-03 13:16:03.244:INFO::main: Logging initialized @222ms to org.seleniumhq.jetty9.util.log.StdErrLog
13:16:03.301 INFO - Driver class not found: com.opera.core.systems.OperaDriver
13:16:03.327 INFO - Driver provider class org.openqa.selenium.ie.InternetExplorerDriver registration is skipped:
registration capabilities Capabilities [{ensureCleanSession=true, browserName=internet explorer, version=, platform=WINDOWS}] does not match the current platform MAC
13:16:03.327 INFO - Driver provider class org.openqa.selenium.edge.EdgeDriver registration is skipped:
registration capabilities Capabilities [{browserName=MicrosoftEdge, version=, platform=WINDOWS}] does not match the current platform MAC
13:16:03.357 INFO - Using the passthrough mode handler
2017-10-03 13:16:03.382:INFO:osjs.Server:main: jetty-9.4.5.v20170502
2017-10-03 13:16:03.407:WARN:osjs.SecurityHandler:main: [email protected]@57536d79{/,null,STARTING} has uncovered http methods for path: /
2017-10-03 13:16:03.411:INFO:osjsh.ContextHandler:main: Started o.s.j.s.ServletContextHandler@57536d79{/,null,AVAILABLE}
2017-10-03 13:16:03.440:INFO:osjs.AbstractConnector:main: Started ServerConnector@5e853265{HTTP/1.1,[http/1.1]}{0.0.0.0:4444}
2017-10-03 13:16:03.441:INFO:osjs.Server:main: Started @419ms
13:16:03.441 INFO - Selenium Server is up and running

It seems like the recent dot release changed something where with Firefox 58 testing we now get:

Suite firefox on linux 4.15.0-1035-aws - signin token code FAILED
InvalidArgument: [POST http://localhost:4444/wd/hub/session/b36ca15a-1246-44de-80b4-69f012454baf/window / {"name":"2147483683"}] missing field `handle` at line 3 column 1
Build info: version: '3.141.59', revision: 'e82be7d358', time: '2018-11-14T08:25:53'
System info: host: '356e9606de2d', ip: '192.168.80.3', os.name: 'Linux', os.arch: 'amd64', os.version: '4.15.0-1035-aws', java.version: '1.8.0_212'
Driver info: driver.version: unknown
  at Command.<anonymous>  <tests/functional/lib/helpers.js:402:12>
  at Command.<anonymous>  <tests/functional/lib/helpers.js:399:6>
  at Command.<anonymous>  <tests/functional/lib/helpers.js:60:23>
  at Command.<anonymous>  <tests/functional/lib/helpers.js:73:18>
  at Command.<anonymous>  <tests/functional/lib/helpers.js:68:10>
  at Command.<anonymous>  <tests/functional/lib/helpers.js:443:6>
  at Command.<anonymous>  <tests/functional/lib/helpers.js:60:23>
  at Command.<anonymous>  <tests/functional/lib/helpers.js:68:10>
  at Suite.beforeEach  <tests/functional/sign_in_token_code.js:51:8>
  at <src/lib/Suite.ts:383:26>
  at runLifecycleMethod  <src/lib/Suite.ts:351:13>
  at next  <src/lib/Suite.ts:522:32>

We are gonna try to update firefox for this case to see if that fixes it

Add a new tunnel provider that downloads and runs Selenium (and configurable optional dependencies like ChromeDriver, IEDriverServer, etc.) on the local machine.

This should be pretty easy since TestingBot already uses a Java application so that code can pretty much just be taken and lightly edited into a new tunnel.

Description
Can't start Selenium version 3.0.0+ with SeleniumTunnel. The root cause appears to be related to the new requirement that "-D" parameters be passed to the java CLI before the "-jar" parameter. See SeleniumHQ/selenium#2566 for additional details.

Steps to Reproduce
digdug: 1.5.0
Node: 4.1.1
OS: Mac OS X El Capitan (10.11.6)

• When starting the Intern test runner, pass in a config that specifies a Selenium version that's >=3.0.0.
• Selenium is not started and an exception is thrown (see below).

Expected Result
DigDug starts Selenium 3.0.0+.

Actual Result
Selenium fails to start. Here's a sample stack trace:

`Listening on 0.0.0.0:9000
Error: Tunnel failed to start: Exception in thread "main" com.beust.jcommander.ParameterException: Unknown option: -Dwebdriver.chrome.driver=/Users/bpartridge/forward/fwd/web/src/main/resources/web/node_modules/intern/node_modules/digdug/selenium-standalone/chromedriver
at com.beust.jcommander.JCommander.parseValues(JCommander.java:742)
at com.beust.jcommander.JCommander.parse(JCommander.java:282)
at com.beust.jcommander.JCommander.parse(JCommander.java:265)
at com.beust.jcommander.JCommander.(JCommander.java:210)
at org.openqa.grid.selenium.GridLauncherV3$1.setConfiguration(GridLauncherV3.java:219)
at org.openqa.grid.selenium.GridLauncherV3.buildLauncher(GridLauncherV3.java:147)
at org.openqa.grid.selenium.GridLauncherV3.main(GridLauncherV3.java:73)

at handleChildExit <node_modules/intern/node_modules/digdug/Tunnel.js:336:16>
at ChildProcess. <node_modules/intern/node_modules/digdug/Tunnel.js:371:6>
at emitTwo events.js:92:20
at ChildProcess.emit events.js:172:7
at Process.ChildProcess._handle.onexit <internal/child_process.js:200:12>`

I'd be happy to submit a PR for this if that would help.

When configuring with Edge locally, is it edge or MicrosoftEdge?

Please verify and update if necessary at https://theintern.io/docs.html#Dig%20Dug/2/api/SeleniumTunnel/seleniumtunnel-1

In my case I'm under http proxy with authentication and executing functional tests on Sauce Labs with Intern. Dig dug is trying to connect with Sauce Labs API (trying to send job status update) using https and this seems to be a problem when combined with http proxy with authentication. I was able to fix that issue by changing the "SauceLabsTunnel.js" code and using the "request" library from here:
https://github.com/request/request
https://www.npmjs.com/package/request

See here for a updated code snippet that works for me (SauceLabsTunnel.js):

//...
var request = require('request');
//...

sendJobState: function (jobId, data) {

var url = urlUtil.parse(this.restUrl || 'https://saucelabs.com/rest/v1/');
url.auth = this.username + ':' + this.accessKey;
url.pathname += this.username + '/jobs/' + jobId;

payload = JSON.stringify({
build: data.buildId,
'custom-data': data.extra,
name: data.name,
passed: data.success,
public: data.visibility,
tags: data.tags
});

var result = new Promise.Deferred();

request({
body: payload,
headers: {
"accept":"application/json"
},
auth : {
"username" : this.username,
"password" : this.accessKey
},
method : "PUT",
proxy: this.proxy,
url : urlUtil.format(url)

}, function (error, response, body) {
response.data = body;
result.resolve(response);
});

return result.promise.then(function (response) {
if (response.data) {
var data = JSON.parse(response.data);

if (data.error) {
throw new Error(data.error);
}

if (response.statusCode !== 200) {
throw new Error('Server reported ' + response.statusCode + ' with: ' + response.data);
}
}
else {
throw new Error('Server reported ' + response.statusCode + ' with no other data.');
}
});
},
//...

I think the same issue occurs when Dig Dug is trying to download the zip file with sauce connect and it would need to be updated in similar way.
Would it be possible to include those fixes in official release?

Thanks,
Bartosz

In Selenium 3, the -debug flag takes an argument (i.e., -debug true).

Also, when verbose mode is enabled, we shouldn't remove the output logger in _start after the tunnel is fully started.

Description
SeleniumTunnel fails to download GeckoDriver for versions 0.10.0+ on Mac OS X. The root cause seems to be that for GeckoDriver versions 0.10.0+, the downloadable is named "geckodriver-v{version}-macos.tar.gz" instead of "geckodriver-v{version}-mac.tar.gz", which was the case for all previous versions.

Steps to Reproduce
digdug: 1.5.0
Node: 4.1.1
OS: Mac OS X El Capitan (10.11.6)

• Start the Intern test runner, passing in a config object that includes the following:

{ environments: [{browserName: "firefox"}], tunnel: "SeleniumTunnel", tunnelOptions: { version: "3.0.1", drivers: [ { name: "firefox", version: "0.11.1", }, ], }, ... }

• The geckodriver executable is not downloaded to the digdug/selenium-standalone directory and an exception is thrown (see below).

Expected Result
SeleniumTunnel downloads GeckoDriver executable for version 0.10.0+ and starts the tunnel as normal.

Actual Result
The executable is not downloaded and the tunnel fails to start. Here's a sample stack trace:

Listening on 0.0.0.0:9000 Tunnel started Suite firefox on any platform FAILED UnknownError: [POST http://localhost:4444/wd/hub/session / {"desiredCapabilities":{"name":"test/functional/intern-config","idle-timeout":60,"browserName":"firefox","marionette":true}}] The driver executable does not exist: /Users/bpartridge/forward/fwd/web/src/main/resources/web/node_modules/intern/node_modules/digdug/selenium-standalone/geckodriver at Server.createSession <node_modules/intern/node_modules/leadfoot/Server.js:330:15> at <node_modules/intern/lib/executors/Runner.js:200:23> at retry <node_modules/intern/lib/util.js:804:13> at <node_modules/intern/node_modules/dojo/Promise.ts:393:15> at runCallbacks <node_modules/intern/node_modules/dojo/Promise.ts:11:11> at <node_modules/intern/node_modules/dojo/Promise.ts:317:4> at run <node_modules/intern/node_modules/dojo/Promise.ts:237:7> at <node_modules/intern/node_modules/dojo/nextTick.ts:44:3> at doNTCallback0 <node.js:407:9> at process._tickCallback <node.js:336:13>

I'd be happy to submit a PR for this if that would help.

The current one depends on graceful-fs 3, which npm warns will stop working at some point.

Hi,
Option useSauceConnect=false really saved time to manually launch SauceConnect, rather than having a new tunnel created each time a grunt task runs.

It is no longer supported with Intern 2.x, is there a replacement?

WebDriver config options (at least for 'version') are being ignored. The problem is that the driver config classes are using implicit initializers for their properties. These end up being set after the options have been applied.

It currently uses fs.exists rather than fs.existsSync, which means that the tunnel executable will always be downloaded.

Follow Intern's model -- prose docs in the repo under docs/, API docs in gh-pages.

Review existing docs and clean up/update as necessary. Remove purely prose docs from the source and add to markdown files in docs/.

I've asked on StackOverflow http://stackoverflow.com/questions/26681808/intern-2-configuration-for-browserstack-behind-a-proxy and on IRC.
Current documentation is not sufficient to understand what configuration to use when behind a proxy using BrowserStack. It's a common problem with proxies and IMO, is documented better in other libraries. If this isn't a bug a constructive criticism would be your documentation is incomplete.

Repeating the StackOverflow question:

I'm unsure what the configuration should be running intern 2 tests against BrowserStack when running behind a proxy/firewall and currently seeing errors/timeouts.

My Current configuration is:

proxyPort : 9000,
proxyUrl : 'http://localhost:9000',
tunnel : 'BrowserStackLocal',
tunnelOptions : {
username : 'myusername',
accessKey : 'myaccesskey',
hostname : '<myproxyip>',
proxy : 'http://<myproxyip>:<myproxyport>'
}
``` I don't think I need `hostname` however if I remove that I immediately see the error `getaddrinfo ENOTFOUND`. 

If use the above configuration it seems to get further, waits for a while then see: 

Listening on 0.0.0.0:9000
Starting tunnel...
BrowserStackLocal v3.3
Connecting to BrowserStack using WebSocket protocol...
Connected.
Ready
Error: [POST http://(redacted)@:4444/wd/hub/session] connect ETIMEDOUT
Error: connect ETIMEDOUT
at errnoException net.js:904:11
at Object.afterConnect [as oncomplete] net.js:895:19
FATAL ERROR
Error: [POST http://(redacted)@:4444/wd/hub/session] connect ETIMEDOUT
Error: connect ETIMEDOUT
at errnoException net.js:904:11
``` The [POST http://(redacted)@<myproxyip>:4444/wd/hub/session] url doesn't seem right. Obviously I have this misconfigured & would appreciate any advice. I do struggle to understand intern's documentation when running behind a proxy.

Ref: https://docs.saucelabs.com/reference/sauce-connect/#command-line-options

Currently the SauceTunnel does not comma separate, but space separates the domains:

Passing -debug true to Selenium 3.5.0 causes Selenium to error out.

See 2ba842e#commitcomment-24727009

• How tunnelOptions works

Tunnel drivers are downloaded to directories in @theintern/digdug/selenium-standalone based on the driver version. This allows dig dug to download download a new version of a driver binary when an existing version of the binary has already been downloaded (e.g., if a user already has IEDriverServer vX but tells dig dug to use vY, dig dug knows the existing one isn't the requested one).

However, there are cases when the processor architecture is significant as well. For example, each version of IEDriverServer comes in win32 and x64 variants. If a user has already downloaded the x64 variant, switching to the win32 would require the user to take some manual action, such as removing the existing driver or reinstalling dig dug.

In summary, driver directories should include the processor architecture as well as the version.

The way in which the latest ChromeDrivers are released changed.
They are no longer published on https://chromedriver.chromium.org/downloads and https://chromedriver.storage.googleapis.com/, but instead here: https://googlechromelabs.github.io/chrome-for-testing/.
Can we update digdug to support this, as we are still using Intern for testing our product.

We recently added support for CrossBrowserTesting, but the README was not updated.