New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support headless configuration for Firefox in selenium-webdriver package #4591

Open
mykmelez opened this Issue Aug 28, 2017 · 11 comments

Comments

Projects
None yet
8 participants
@mykmelez

mykmelez commented Aug 28, 2017

OS: Windows, macOS, Linux
Selenium Version: 3.5.0
Browser: Firefox
Browser Version: 56

Once Firefox supports headless mode on all three platforms (starting with Firefox 56, currently in beta and due to be released next month), the selenium-webdriver package should support configuring Firefox to run headlessly the same way it supports Chrome running headlessly, via a headless() method on the Firefox driver's Options class, so that you can drive Firefox headlessly via:

const { Builder } = require('selenium-webdriver');
const firefox = require('selenium-webdriver/firefox');
const driver = new Builder()
.forBrowser('firefox')
.setFirefoxOptions(new firefox.Options().headless())
.build();

(It would additionally be useful to be able to set the headless window's size via the equivalent of Chrome's windowSize({width, height}) method.)

@barancev

This comment has been minimized.

Show comment
Hide comment
@barancev

barancev Aug 30, 2017

Member

This option should be added to all language binding.

Member

barancev commented Aug 30, 2017

This option should be added to all language binding.

@barancev

This comment has been minimized.

Show comment
Hide comment
@barancev

barancev Sep 4, 2017

Member

Implemented in Java binding by 38a5130

Member

barancev commented Sep 4, 2017

Implemented in Java binding by 38a5130

@barancev barancev removed the C-java label Sep 4, 2017

@franzliedke

This comment has been minimized.

Show comment
Hide comment
@franzliedke

franzliedke Sep 26, 2017

Contributor

As far as I can tell, this is already possible with the Ruby bindings:

options = Selenium::WebDriver::Firefox::Options.new(
  args: ['-headless']
)

Selenium::WebDriver.for :firefox, options: options
Contributor

franzliedke commented Sep 26, 2017

As far as I can tell, this is already possible with the Ruby bindings:

options = Selenium::WebDriver::Firefox::Options.new(
  args: ['-headless']
)

Selenium::WebDriver.for :firefox, options: options
@lmtierney

This comment has been minimized.

Show comment
Hide comment
@lmtierney

lmtierney Sep 26, 2017

Member

@franzliedke yes it is most likely possible with all bindings, but this is asking for a shortcut without having to specify it in args

Member

lmtierney commented Sep 26, 2017

@franzliedke yes it is most likely possible with all bindings, but this is asking for a shortcut without having to specify it in args

@mykmelez

This comment has been minimized.

Show comment
Hide comment
@mykmelez

mykmelez Sep 26, 2017

Right, note that Chrome already supports this configuration in selenium-webdriver:

* __Headless Chrome__ <a id="headless"></a>
*
* To start Chrome in headless mode, simply call
* {@linkplain Options#headless Options.headless()}. Note, starting in headless
* mode currently also disables GPU acceleration.
*
* let chrome = require('selenium-webdriver/chrome');
* let {Builder} = require('selenium-webdriver');
*
* let driver = new Builder()
* .forBrowser('chrome')
* .setChromeOptions(new chrome.Options().headless())
* .build();

And selenium-webdriver also provides an example script using it:

https://github.com/SeleniumHQ/selenium/blob/master/javascript/node/selenium-webdriver/example/chrome_headless.js

Although strangely the docs don't mention it:

http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/chrome_exports_Options.html

This issue is about doing the same for Firefox. It may be merely syntactic sugar, but it's useful nonetheless.

mykmelez commented Sep 26, 2017

Right, note that Chrome already supports this configuration in selenium-webdriver:

* __Headless Chrome__ <a id="headless"></a>
*
* To start Chrome in headless mode, simply call
* {@linkplain Options#headless Options.headless()}. Note, starting in headless
* mode currently also disables GPU acceleration.
*
* let chrome = require('selenium-webdriver/chrome');
* let {Builder} = require('selenium-webdriver');
*
* let driver = new Builder()
* .forBrowser('chrome')
* .setChromeOptions(new chrome.Options().headless())
* .build();

And selenium-webdriver also provides an example script using it:

https://github.com/SeleniumHQ/selenium/blob/master/javascript/node/selenium-webdriver/example/chrome_headless.js

Although strangely the docs don't mention it:

http://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/chrome_exports_Options.html

This issue is about doing the same for Firefox. It may be merely syntactic sugar, but it's useful nonetheless.

@franzliedke

This comment has been minimized.

Show comment
Hide comment
@franzliedke

franzliedke Sep 27, 2017

Contributor

Thanks for clarification. I sent a PR for the Ruby bindings: #4762.

Contributor

franzliedke commented Sep 27, 2017

Thanks for clarification. I sent a PR for the Ruby bindings: #4762.

@p0deje p0deje removed the C-rb label Sep 29, 2017

@jleyba jleyba self-assigned this Oct 3, 2017

@jleyba jleyba closed this in 5bf50c4 Oct 6, 2017

@jleyba jleyba reopened this Oct 6, 2017

@jleyba jleyba removed the C-nodejs label Oct 6, 2017

@jleyba jleyba removed their assignment Oct 6, 2017

@lmtierney lmtierney removed the C-py label Nov 16, 2017

@lmtierney

This comment has been minimized.

Show comment
Hide comment
@lmtierney

lmtierney Nov 16, 2017

Member

Added to python in 1d490b4

Member

lmtierney commented Nov 16, 2017

Added to python in 1d490b4

@DaleGardner

This comment has been minimized.

Show comment
Hide comment
@DaleGardner

DaleGardner Jan 31, 2018

dotnet please! 🙏

DaleGardner commented Jan 31, 2018

dotnet please! 🙏

@jimevans

This comment has been minimized.

Show comment
Hide comment
@jimevans

jimevans Jan 31, 2018

Member

I’m hoghly disinclined to implement this for .NET. It was a mistake for other bindings to implement it as well. The ability to add commmsnd line arguments to both Firefox and Chrome is there already; use the AddArgument method in the respective Options classes. Why special case “headless”? It wouldn’t make the user’s code any more or less verbose, plus it obscures the browser configuration (i.e., “how is a browser made to run ‘headless’?”). I’m not sure I fully understand the use case.

Member

jimevans commented Jan 31, 2018

I’m hoghly disinclined to implement this for .NET. It was a mistake for other bindings to implement it as well. The ability to add commmsnd line arguments to both Firefox and Chrome is there already; use the AddArgument method in the respective Options classes. Why special case “headless”? It wouldn’t make the user’s code any more or less verbose, plus it obscures the browser configuration (i.e., “how is a browser made to run ‘headless’?”). I’m not sure I fully understand the use case.

@jleyba

This comment has been minimized.

Show comment
Hide comment
@jleyba

jleyba Jan 31, 2018

Contributor

@jimevans I see this as a case of the API can expose a common config option without requiring users to be intimately familiar with a browser's command line arguments. It's not unlike having strongly typed APIs for capabilities vs. expecting users to know all of the various key/value pairs.

Contributor

jleyba commented Jan 31, 2018

@jimevans I see this as a case of the API can expose a common config option without requiring users to be intimately familiar with a browser's command line arguments. It's not unlike having strongly typed APIs for capabilities vs. expecting users to know all of the various key/value pairs.

@jimevans

This comment has been minimized.

Show comment
Hide comment
@jimevans

jimevans Feb 1, 2018

Member

I understand the analogy, @jleyba, I just don’t think I agree with it. Capabilities are a much smaller finite set of settings. To me, it’s really hard to justify adding an API for a single command line argument while ignoring the potentially dozens of others.

Member

jimevans commented Feb 1, 2018

I understand the analogy, @jleyba, I just don’t think I agree with it. Capabilities are a much smaller finite set of settings. To me, it’s really hard to justify adding an API for a single command line argument while ignoring the potentially dozens of others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment