Using custom DesiredCapabilities (via JS API)

[JonasHavers]

Sometimes it is required to pass additional parameters to the selenium web driver. This can be done by defining custom "DesiredCapabilities". Unfortunately, the current Galen JS API lacks this feature.

To be backwards compatible, extend the createDriver method from the JS API to be passed an optional DesiredCapabilities parameter. After conversion of the Map<String, ?> parameter value, the DesiredCapabilities could be passed to the RemoteWebDriver constructor, e.g. to the ChromeDriver constructor in your SeleniumBrowserFactory.

ChromeOptions uses DesiredCapabilities underneath, so I think this would also be a valid solution to other issues like #94.

The issue I have is that I want to start Chrome in headless mode (see https://developers.google.com/web/updates/2017/04/headless-chrome) which would require me to pass these options:

capabilities: {
    chromeOptions: {
      args: [
        "--headless",
        "--disable-gpu"
      ]
    }
  }

In addition to the JS API extension or instead of it, we could read the capabilities from the Galen config properties file. The capabilities could be passed as a capabilities property or generic properties with a fixed prefix. That would provide a solution to #342.

[patriksima]

Is possible add to galen.config something like this?

$.webdriver.chrome.driver=/opt/google/chrome/chrome
$.webdriver.chrome.driver.args=--headless --disable-gpu --remote-debugging-port=9222

[ishubin]

@wrongware No, that $ symbol is actually just a hacky way of setting default system properties in galen. And that system property webdriver.chrome.driver is used by ChromeDriver class which is managed in selenium lib, so galen has nothing to do with it. Therefore extending it is not an option.

As for the whole issue in general I am still not sure what is the best way of dealing with it. It has to work for all drivers and not just for ChromeDriver. Also the issue itself is not of a high priority, due to the fact that the users are still able to control driver creation themselves. The createDriver was just a simple function that was supposed to provide simple access to driver. It was never planned to turn it into advanced configuration.

[BlacktoBlue]

@ishubin I am looking to create a custom driver as I need the --no-sandbox Option. Can you provide me with a bit of example JS that I can use to create the driver please?

[t2hv33]

Can anyone help me to create an example JS that I can use to create the driver with Capabilities, please? @hypery2k

[hypery2k]

Yyou could setup an selenium grid and configure all browser settings then in the grid instead of Galen

[Jiff21]

I'm trying to start this on a selenium grid using the Grid Instructions.

I'm using the following line in my .test file to launch grid: selenium grid http://localhost:4444/wd/hub --browser chrome --platform "ANY" --dc.chromeOptions "{args: [headless], extensions: []}, version: " --page ${base_url}/ --size ${large_desktop_dimensions}

But looking at the selenium hub's log, it looks like something in Galen is shortening the text that I'm passing to the --dc. option. The selenium hub log for my .text file show: INFO - Got a request to create a new session: Capabilities {browserName: chrome, chromeOptions: {args: [headless], extensio...} Instead of: INFO - Got a request to create a new session: Capabilities {browserName: chrome, chromeOptions: {args: [headless], extensions: []}, version: } that appears when I start a headless test through normal python. Or Selenium is concatenating it for some reason.

I tried using --dc.chromeOptions "{args: [headless]}, version: ", --dc.chromeOptions "{args: [headless], extensions: []}" & --dc.chromeOptions "{args: [headless]}" which don't show as shortened but these cause unknown error: cannot parse capability: chromeOptions errors as well.

Galen Version Version: 2.3.6 JavaScript executor: Rhino 1.7 release 5 2015 01 29