Hacker News Reader

Comment by robk | Hacker News Reader

It's not very clear how to actually use this in a test environment like Selenium etc. At least with headless Chrome there are libraries now to drive it via the remote debug protocol like https://github.com/LucianoGanga/simple-headless-chrome

This feels a little nicer than Selenium as it's one less layer of abstraction.

EDIT: guess from other comments WebDriver is the right method to access.

View on HN

SlimerJS [0] and Selenium WebDriver are the main APIs supported at the moment. Setting MOZ_HEADLESS=1 or providing the --headless flag to Firefox will launch in headless mode.

It should be mentioned that this is an area of active development. I don't believe headless mode has been "officially" announced yet; documentation should follow when that happens. Optimization, more APIs, more platforms, and easy deployment are in the pipeline. The meta bug for tracking is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1338004

(Disclaimer: I'm an intern at Mozilla, working with 'brendandahl on headless right now.)

[0] https://slimerjs.org/

The Chrome Devtools API is really useful. However, if you're wanting to use Selenium, a coworker of mine wrote this up to show how to use headless Chrome with Python + Selenium https://duo.com/blog/driving-headless-chrome-with-python

I would imagine the same approach could be used here with minimal changes.

Would people find it helpful if I add a `headless` capability to `moz:firefoxOptions` in geckodriver so that passing in `{capabilities: {alwaysMatch: {moz:firefoxOptions:{headless: true}}}}` when starting a session will start the browser in headless mode, if supported? This doesn't seem like something that's compelex enough to warrant a whole blogpost to explain how to get it working.

Oh, apparently there's already a flag you can pass to the binary to enable headless mode, and geckodriver already supports setting those, so adding a separate option seems unnecessary. I thought it was just an environment variable.

FWIW, from the Chome side, we think there's more power via the protocol rather than WebDriver.

On the Firefox side, we are considering supporting the protocol or a subset of it. It seems many people have had lots of trouble with WebDriver/Selenium in the past and are hesitant to use it. However, it is nice that WebDriver has a W3C standard which could provide a nice path forward for headless cross browser use. This would probably require browser vendors to make it a first class citizen and work out some the kinks of the spec though.

BTW, I'm in Mozilla San Francisco office, so I'd be happy to chat about the headless cross browser future if anyone from the headless Chrome team is around.

Well, yes, a low level protocol is going to have at least the same features as a higher level protocol implemented in terms of it. However I think you should mention the significant disadvantages of using a nonstandard API:

* Doesn't generalise to driving other browsers. Using a standardised API gives you the possibility to run your automation against any top tier browser. If you are testing a website this ought to be a top consideration.

* Uncertain compatibilty story. I assume that the devtools protocol can change at the whim of the Chrome team. Using something standardised means that your tests and client are more likely to continue working.

* More limited selection of clients. WebDriver in particular has a large number of production-grade clients that are actively maintained.

I'm not claiming that WebDriver is perfect; certainly if I designed it from scratch it would look very different. And yes, there is a period of churn as it moves toward being a standard. But I think the advantages of cross-browser support are a compelling reason for it to be the default tool for remote automation tasks that are within the scope of its featureset. By all means, if you have something that cannot be done with a standardized technology look at the proprietary solutions. But I don't think it should be your first pot of call.

All of these look like advantages if you're building a monopoly and have a contempt for anything that slows that down.

(Note: I'm the product manager for the headless browsing feature of Firefox.)

I chose to prioritize WebDriver support because it's a popular way to drive headed Firefox, and I wanted to make it as easy as possible for existing WebDriver users to use headless.

For use cases that are not well-served by WebDriver, I've considered supporting the Chrome DevTools Protocol, as @brendandahl noted, although I haven't yet made a decision to do so.

I'm interested to hear more about the use cases you've considered for which WebDriver is a suboptimal solution. Like @brendandahl, I'm in the Bay Area and would be happy to meet in SF or MV.

for automated testing in a non windowed env, this can be used.

Reply on news.ycombinator.com