It should be pretty similar on Linux, and probably macOS when it comes around.
> "c:\Program Files\Nightly\firefox.exe" -headless
(It also works when Firefox is invoked from a Node.js script in a test suite for a Node.js program that drives Firefox.)
Perhaps this is a Selenium issue?
Support headless flag on Linux, RESOLVED FIXED in Firefox 55
If you are blocked it may be worth a look
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.
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.)
I would imagine the same approach could be used here with minimal changes.
* 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.
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.
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.
2. Firefox's WebDriver endpoint geckodriver is a layer above Firefox/Gecko's native Marionette protocol
So you doubly don't need to use selenium, you can write your own WebDriver client (which should be cross-browser assuming the browsers either support WebDriver natively or have a WD layer of some sort installed) or you can use raw Marionette (either a hand-rolled client or an existing client)
Edit: It's possible. It's on the introduction page of Chrome Headless
Look at 'Create a PDF'
PhantomJS made the process pretty easy, but that's probably not a good option these days as it's on the way out.
NightmareJS is pretty much the same and can do it (though I haven't tested myself) 
If you want to get a little deeper you can use CEF (Chromium Embedded Framework [1
]. It basically turns Chrome into a library and there are a bunch of projects that build on top of it (eg Electron, which is what NightmareJS uses underneath).
Here's a project that just uses CEF for converting to PDF .
There's also only very rudimentary support for page headers and footers.
wkhtmktopdf is probably ok if you just need a quick single page invoice printout, but the moment you need more (in our case, we definitely do), I can highly recommend paying for https://www.princexml.com/ which has support for a lot of printing specific features.
We wanted the same view to be passed into wkhtmltopdf to download it as PDF (with a couple of things omitted).
Unfortunately, the JS didn't execute properly, so you get a borked output.
End result was we render it, capture the HTML after render, and pipe that through to wkhtmltopdf.
Using chrome _should_ resolve that issue and let us just pass the page through.
Here's an example fully rendered in React:
And one with svg charts:
With -webkit- prefixes you can use even flexbox, and and with js polyfills you'll have all you need.
Of course if I would start a project now, I would use chrome headless, but I don't feel wkhtmltopdf is that bad.
1) Theming of form controls to make them look like native widgets.
4) Fonts and font rendering.
5) General "now it's time to repaint" machinery.
This is in no way an exhaustive list. In practice what you have to do for headless is create the relevant GUI bits anyway, but not actually show them on screen, then deal with whatever quirks your GUI library has when its bits are not shown.
One slight complication of headless has been wiring up the headless "widgets" (in Firefox, we refer to most of the platform specific code as widgets e.g. there's gtk widgets, cocoa widgets, windows widgets). Usually the widget type is defined statically at build time, but in the case of headless we wanted Firefox to either use the headless widgets or the platform specific widgets at runtime. Luckily, some of the work on multi-process Firefox work also added another type of widget and made it much easier to support multiple types of widgets.
Overall, the hardest part has been trying to replicate all the events that would normally be triggered by the platform gui code. I've also found that these events and order can vary per platform which makes it hard to do in a non-platform specific way. We're still working out some issues here.
WebDriver or Marionette.
Joke aside: can somone explain "headless" to me here?
Uses include rendering a screenshot (e.g. a preview thumbnail) of some website on a server, or running automated UI tests that click around a web app and fill out forms to verify its functionality.
Edit: looking at the code, it will work just fine, and that means I can even use it myself to run Firefox's unit and integration tests, I usually use xvfb on Linux.
Of course headless is also needed as the PhantomJS solution is not maintained anymore since April. See discussion here: https://news.ycombinator.com/item?id=14105489
The sometimes really make it hard for us fanboys (prism, Brendan and uncertainty about the future of extensions) :-|
Poke me when there are no X11/Qt/GTK/whatever dependencies at all - that is headless.
So it's going to need a UI rendering and interaction library.
I doubt it'll happen anytime too soon, but Mozilla should see the community interest.
Which is certainly the obvious primary use case for headless browsers.
Not that Firefox itself is particularly lightweight.