Skip to content
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

Closed
mykmelez opened this issue Aug 28, 2017 · 12 comments
Closed

Comments

@mykmelez
Copy link

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
Copy link
Member

This option should be added to all language binding.

@barancev
Copy link
Member

barancev commented Sep 4, 2017

Implemented in Java binding by 38a5130

@barancev barancev removed the C-java label Sep 4, 2017
@franzliedke
Copy link
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

@lmtierney
Copy link
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

@mykmelez
Copy link
Author

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
Copy link
Contributor

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

@lmtierney
Copy link
Member

Added to python in 1d490b4

@DaleGardner
Copy link

dotnet please! 🙏

@jimevans
Copy link
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.

@jleyba
Copy link
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
Copy link
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.

@diemol
Copy link
Member

diemol commented May 21, 2020

Closing as it was resolved after reading the comments.

@diemol diemol closed this as completed May 21, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Sep 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants