4 ms·

If you're using Go, https://github.com/knq/chromedp https://github.com/knq/chromedp It's also worth noting that the 57+ series has a nice embedded viewer you c

by kenshaw 10y ago

If you're using Go, https://github.com/knq/chromedp https://github.com/knq/chromedp It's also worth noting that the 57+ series has a nice embedded viewer you can use to view the actual viewport via devtools.

nojvek 10y ago
If you want great code completion for chrome's large devtools api with lots of different kinds of object then https://www.npmjs.com/package/chrome-remote-debug-protocol https://www.npmjs.com/package/chrome-remote-debug-protocol It dynamically generates Typescript definitions for intelligence and type checking from their protocol.json files. Vscode chrome debugger uses a fork of it. I'm the author. /shamelessplug
chrissnell 10y ago
WOW. That's fantastic. As I noted in a comment above, I wrote a tool called crabby that uses Selenium and Chrome headless to do automated page testing and to report results back to metrics engines like Graphite, Datadog, Prometheus, and Riemann. The biggest problem I have is the unreliability of chromedriver and the extreme resource consumption of Chrome + Selenium. It's really too much for your average public cloud instance if you want to test any more than, say, one or two pages a minute. Do you know if chromedp can access any of the timing measurements?
- kenshaw 10y ago
  Yes, you can access everything via the underlying APIs. chromedp is a relatively new project (only about 4 months old), so there isn't much yet in the way of high level timing / profiling, but we hope to add that to the code base when we have some bandwidth to do so.
vvoyer 10y ago
Can you detail what is the embedded viewer and how/when you access it? Thanks.
- kenshaw 10y ago
  With either Chrome in headless mode, or "headless_shell" (a minimal Chrome app part of the Chromium source tree), you first enable the remote debugging port (via --remote-debugging-port=9222), and then you can then simply browse to http://localhost:9222/ http://localhost:9222/. That web page will list the various Chrome "pages" (ie, tabs) which you can then click on. Clicking on those tabs will open the Chrome DevTools inside of Chrome, as a web app served from http://localhost:9222/ http://localhost:9222/. This is the internal API that DevTools uses, and is what is referred to as the "Chrome Debugging Protocol" (ie, chromedp). Since 57+, the built in DevTools UI displays whatever the active viewport Chrome "sees" using the screencast APIs. It's just a PNG that's updated every couple hundred milliseconds with the output of Chrome's headless renderer.
  - vvoyer 10y ago
    Thanks, also did not quite understood what exactly was headless_shell: how to run it, pro/cons, when to use it versus chrome headless.
    - swah 10y ago
      The documentation seems to be the source at this moment: https://chromium.googlesource.com/chromium/src/+/lkgr/headless/app/headless_shell.cc https://chromium.googlesource.com/chromium/src/+/lkgr/headle... Its a binary that I suppose runs the Chrome in headless mode, supports some command line options like --screenshot to take screenshots, etc. I'm having a hard time understanding why its hanging on some runs, and how --timeout and --virtual-time-budget could help me with this.

by kenshaw 10y ago

nojvek 10y ago

If you want great code completion for chrome's large devtools api with lots of different kinds of object then https://www.npmjs.com/package/chrome-remote-debug-protocol https://www.npmjs.com/package/chrome-remote-debug-protocol It dynamically generates Typescript definitions for intelligence and type checking from their protocol.json files. Vscode chrome debugger uses a fork of it. I'm the author. /shamelessplug

chrissnell 10y ago

WOW. That's fantastic. As I noted in a comment above, I wrote a tool called crabby that uses Selenium and Chrome headless to do automated page testing and to report results back to metrics engines like Graphite, Datadog, Prometheus, and Riemann. The biggest problem I have is the unreliability of chromedriver and the extreme resource consumption of Chrome + Selenium. It's really too much for your average public cloud instance if you want to test any more than, say, one or two pages a minute. Do you know if chromedp can access any of the timing measurements?

kenshaw 10y ago
Yes, you can access everything via the underlying APIs. chromedp is a relatively new project (only about 4 months old), so there isn't much yet in the way of high level timing / profiling, but we hope to add that to the code base when we have some bandwidth to do so.

vvoyer 10y ago

Can you detail what is the embedded viewer and how/when you access it? Thanks.

kenshaw 10y ago
With either Chrome in headless mode, or "headless_shell" (a minimal Chrome app part of the Chromium source tree), you first enable the remote debugging port (via --remote-debugging-port=9222), and then you can then simply browse to http://localhost:9222/ http://localhost:9222/. That web page will list the various Chrome "pages" (ie, tabs) which you can then click on. Clicking on those tabs will open the Chrome DevTools inside of Chrome, as a web app served from http://localhost:9222/ http://localhost:9222/. This is the internal API that DevTools uses, and is what is referred to as the "Chrome Debugging Protocol" (ie, chromedp). Since 57+, the built in DevTools UI displays whatever the active viewport Chrome "sees" using the screencast APIs. It's just a PNG that's updated every couple hundred milliseconds with the output of Chrome's headless renderer.
- vvoyer 10y ago
  Thanks, also did not quite understood what exactly was headless_shell: how to run it, pro/cons, when to use it versus chrome headless.
  - swah 10y ago
    The documentation seems to be the source at this moment: https://chromium.googlesource.com/chromium/src/+/lkgr/headless/app/headless_shell.cc https://chromium.googlesource.com/chromium/src/+/lkgr/headle... Its a binary that I suppose runs the Chrome in headless mode, supports some command line options like --screenshot to take screenshots, etc. I'm having a hard time understanding why its hanging on some runs, and how --timeout and --virtual-time-budget could help me with this.