Hacker News new | comments | show | ask | jobs | submit login

No mention of WebDriver, only Chrome's devtools protocol :( There's probably a proxy or something, but would be nice to see completely integrated native support.

That proxy already exists. It is called ChromeDriver[1][2] and was developed in collaboration between the Chromium and Selenium teams. It is the same way that Selenium/Webdriver controls regular Chrome now.

It would have been nice if they at least mentioned it in the article since Selenium is such a popular browser automation tool. They do in fact mention it on the README page for headless chromium.

[1] https://github.com/SeleniumHQ/selenium/wiki/ChromeDriver

[2] https://sites.google.com/a/chromium.org/chromedriver/home

[3] https://chromium.googlesource.com/chromium/src/+/lkgr/headle...

The problem with ChromeDriver is that it implements Selenium's idea of what the remote control interface should look like, and frankly speaking, Selenium's idea has some enormous and idiotic oversights[1].

[1] http://stackoverflow.com/questions/3492541/how-do-i-get-the-...

ChromeDriver also has a particularly annoying race condition when triggering clicks https://bugs.chromium.org/p/chromedriver/issues/detail?id=28 which often only appears on slow machines such as multitenant CI services like CircleCI (https://circleci.com/docs/1.0/chromedriver-moving-elements/)

correct me if I'm wrong, but doesn't webdriver communicate with Chrome via the devtools protocol?

WebDriver is a protocol: https://www.w3.org/TR/webdriver/

yeah yeah yeah I'm sorry I mean Chrome webdriver, I think that was clear from context?

As in selenium -> webdriver protocol -> chrome webdriver -> devtools protocol -> chrome instance

it's called ChromeDriver and I kinda mentioned it originally — "There's probably a proxy or something" — and said that I want native fully integrated support :)

ah now I follow, my bad :)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact