Headless Chrome is coming soon

[jakozaur]

That would be so awesome. The current alternatives:

1. Use PhantomJS: It easy to script, but it lags over real browser by few years and development is stagnant. Many real website doesn't work in PhantomJS.

2. Use Chrome/Firefox xvfb. You have real browser, but scripting is hard. E.g. even hello world examples like make a thumbnail of a website takes a lot of time to get right.

According to some rumors, headless Chrome existed before even Chrome was released to the public. Google use it to do web scraping. However, though headless browsers are great for developers, they are also great for spammers and ad fraud. So the main developer likely has conflict of interests whether to invest resources into making headless Chrome public.

[m0th87]

There's also Nightmare, which is built off Atom. We ported all of our PhantomJS-backed headless tests to Nightmare recently, and it's paid in dividends: http://www.nightmarejs.org

[robin_reala]

Option 3: SlimerJS[1]. We evaluated it for testing CSP2 functionality which WebKit doesn’t yet support.

[1] http://slimerjs.org/

[fauigerzigerk]

Another downside to the selenium API is that there is no way to get any upstream HTTP status or network error. That includes redirects unfortunately.

I'm using a Chrome plugin for that purpose, which complicates the whole setup even further.

[est]

Mozilla Servo has a headless mode, but PITA to get it working.

[andrea_s]

What about Selenium? Is it already covered in point 2?

[ddebernardy]

Another good option is Scrapy combined with Splash.

[juliangamble]

If this would benefit you - please star this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=546953

[frik]

From the bug comments:

  headless: Implement screenshot capturing
  
  (based on patch from skyostil@, also sets default window 
  size to 800x600 to enable basic snapshot support)
  
  With the --screenshot option, headless shell will save a 
  PNG screenshot of the loaded page.

[hkjgkjy]

Just out of curiosity - when does Chrome consider a page "loaded"? Is it the classic window.onload or something fancier?

[jsprogrammer]

I just use XVFB.

  xvfb-run --server-args='-screen 0 1024x768x24 -ac' chromium-browser --user-data-dir <url>

[snuxoll]

I do to, but not for testing (we don't actually do any scripted UI tests, we should, but they are time consuming to write). We have a Python service that uses Firefox, Selenium and XVFB (through the awesome PyVirtualDisplay library, check it out) to log into a website that uses an annoying Java applet + scripting for authentication. This ended up cutting off a huge headache where previously we were doing this in a Windows scheduled task that needed an active console session to do anything.

[joshschreuder]

Could this be used for Selenium tests too? And with visual diff testing tools?

[mhluongo]

I don't see why not. You can do it today with headless options like PhantomJS (headless WebKit), and this seems to be intended for similar uses.

[egeozcan]

The required work for Selenium compatibility is tracked here: https://bugs.chromium.org/p/chromium/issues/detail?id=604324 (And yes, it is a blocking issue).

[emilong]

This is great news. In general I'm hoping this makes it easier to do browser testing in more CI services, rather than isolating this type of testing to services that have to specialize in it just to get it to to work.

One (minor?) benefit over Phantom is having working file uploads, though it would be awesome to have that in Phantom too.

[toasterlovin]

We upload files in our integration tests using PhantomJS. At least, I'm pretty sure we do (we use Capybara to drive PhantomJS). Am I missing something?

[juliangamble]

Another way to solve this problem is to have Chrome in a docker container that you can start up: https://github.com/SeleniumHQ/docker-selenium

[killing_time]

I use the Chrome and Firefox docker-selenium containers in Testcontainers [1][2], my project for running containers to support JUnit tests.

I created this after numerous issues with PhantomJS compatibility and debuggability; Testcontainers instead uses the real browsers, and also offers automatic video recording of test sessions and VNC access for debugging.

Headless chrome support sounds like a good step forward, but if visibility into what's going on is limited then I feel there's going to be some way to go. Perhaps chrome remote debugging support?

[1]: http://testcontainers.viewdocs.io/testcontainers-java/ [2]: https://rnorth.org/26/better-junit-selenium-testing-with-doc...

[fuzionmonkey]

This is awesome. I've been using Electron for browser tests which has been a big improvement over Phantom, but setting up xvfb can be a pain.

[erikb]

Please link the source and not twitter next time.

[gildas]

Great news! I hope this will allow to change the hard-coded limit of the maximum number of connection per server in Chrome [1].

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=85323

[shimon_e]

Isn't chromium already bundled with chromedriver? Or at least it is on arch linux. (fyi, chromedriver conflicts chromium in aur because of this)

[foota]

I believe the difference is that chromedriver still spins up all the normal chrome interface, which wouldn't be needed for the headless chrome. I think the stated deliverables help discern the intention:

1. A library which headless applications can link to to. 2. A sample application which demonstrates the use of headless APIs.

[qznc]

I wanted this 10 years ago. It is fascinating that it took so long already.

[myle]

There was no Chrome browser 10 years ago.

[shanemhansen]

I'm most excited about integration testing on sites with http/2 deployed.