Geckodriver standalone - No way to set browser connection timeout

[jamesaspence]

I am currently attempting to get firefox tests running locally. To that end, I'm spinning up a separate instance of geckodriver via CLI (not using the selenium server). When I change my configuration to point towards firefox, everything is working fine - the browser begins to load. However, firefox loads so slowly that by the time it's finished, nightwatch has killed the connection and assumed the browser is not there. It then throws a connection refused error.

I have not seen anywhere in the docs mentioning the ability to set a startup timeout. Is such a configuration option available?

EDIT: Perhaps this is tied in with the issue described in https://github.com/nightwatchjs/nightwatch/issues/1456 ?

EDIT: Using nightwatch version 0.9.14. I have tried 0.9.16 as well, no change. I have tested this on both firefox version 48 and 53.0.3, same issue.

[jamesaspence]

In the hopes that this helps, here is my configuration: EDIT: updated with new request_timeout_options, no change seen.

const geckodriver = require('geckodriver');
require('../getEnv');
const directory = __dirname;

module.exports = {
    src_folders: [`${directory}/../../specs`],
    custom_commands_path: `${directory}/../../commands`,
    output_folder: `${directory}/../../reports`,
    selenium: {
        start_process: false,
    },
    test_settings: {
        default : {
            launch_url: getEnv('baseUrl'),
            selenium_port: 4444,
            selenium_host: 'localhost',
            request_timeout_options: {
                timeout: 15000,
                retry_attempts: 3
            },
            default_path_prefix : '',
            silent: true,
            screenshots: {
                enabled: getEnv('screenshots', false),
                path: `${directory}/../../screenshots`
            },
            desiredCapabilities: {
                browserName: 'firefox',
                marionette: true
            },
            globals: {
                before: done => {
                    let chai = require('chai');
                    global.expect = chai.expect;
                    chai.Should();
                    geckodriver.start();
                    done();
                },
                after: done => {
                    geckodriver.stop();
                    done();
                },
                isBrowserstack: false
            }
        }
    }
};

I have tried running geckodriver both within this configuration, as well as run it as a standalone process. Regardless of which I do, I end up with a connection refused.

[beatfactor]

You should be able to achieve this with request_timeout_options: http://nightwatchjs.org/gettingstarted#test-settings.

[jamesaspence]

Setting a request timeout makes no difference (the default is set to 60 seconds according to the docs, and this is definitely not waiting for that).

If I understand correctly, request_timeout_options sets the timeout on making HTTP requests. This is appearing to be an issue with connecting to the browser in the first place.

Screenshot of my output included, for clarification:

The lifecycle of what happens is:

• geckodriver is started, seems to finish starting
• Tests are begun, which triggers the browser being opened (thus showing that geckodriver has "connected" properly)
• Error (screenshotted above) appears, no testing occurs
• Subsequent attempts don't open additional firefox windows, but fail immediately with the same message.

Perhaps this issue is not a timeout, but another issue masquerading as a timeout?

[jamesaspence]

To further clarify, I attempted adding request_timeout_options, see above configuration for example

[jamesaspence]

Bump on this? Any idea of what might be causing this? Is this user error or something deeper?

[jamesaspence]

I did some further tests of this, using a standalone selenium server (3.4.0) and geckodriver (0.17.0). I get the browser to open up in the exact same way, and then once again it fails after the browser runs.

EDIT: Here is the output I'm receiving:

Starting selenium server... started - PID:  8288

[Ttbx / Landing / 02 Login] Test Suite
==========================================

Running:  Access login

Error retrieving a new session from the selenium server
Connection refused! Is selenium server started?
{ value:
   { sessionId: '353ad7ae-53ba-1146-ba84-f751c7fd7e5f',
     capabilities:
      { acceptInsecureCerts: false,
        browserName: 'firefox',
        browserVersion: '53.0.3',
        'moz:accessibilityChecks': false,
        'moz:processID': 8289,
        'moz:profile': '/var/folders/88/v9gc2hgn3_d431s2rzx453dc0000gn/T/rust_mozprofile.2LjHJCYLVxXO',
        pageLoadStrategy: 'normal',
        platformName: 'darwin',
        platformVersion: '16.0.0',
        rotatable: false,
        specificationLevel: 0,
        timeouts: [Object] } } }

Based on some logging I did, it appears to be calling Nightwatch.prototype.startSession, returning the above output, erroring out because data.sessionId is not set. However, that appears to be because the data object is wrapped inside of that value key. It needs to search one level down.

[jamesaspence]

The issue is 100% because that response gets returned wrapped in a value key. I can modify the code slightly inside of Nightwatch.prototype.startSession and get it to accept the server running. However, we then fail on the next call / test - I'm guessing because the rest of these calls might be wrapped in a similar way?

Examples:

Chrome response:

{ sessionId: '058084b4c9c29f9303a78a071f553daa',
  status: 0,
  value: null }

Firefox response equivalent:

{ value: { sessionId: '058084b4c9c29f9303a78a071f553daa',
    status: 0,
    value: null } }

~Looks like this might be an issue with SE Server / geckodriver - https://github.com/mozilla/geckodriver/issues/207~

EDIT 2.0 (sorry) - Actually, looks to be intentional - https://github.com/mozilla/geckodriver/releases/tag/v0.15.0

So - chromedriver doesn't appear to be up to that spec, nor is this lib. Both nightwatch and chromedriver apparently are following the old selenium bindings. This issue is bigger than nightwatch, but nonetheless I want to bring it to your attention in the hopes of getting a solution.

[jamesaspence]

Closing this issue since the original issue was not the issue. Instead, for anybody who finds their way here, please instead take a look at issues regarding Nightwatch's compatibility with the W3C Webdriver Standard.