New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 719921 link

Starred by 14 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 546953


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Consider replacing headless_shell runtime switches with a nodejs module + exemplary application

Project Member Reported by eseckler@chromium.org, May 9 2017

Issue description

Folks are starting to rely on headless_shell switches, such as --screenshot and --print-to-pdf, that are intended only to provide examples for the use of DevTools APIs.

It's difficult for users to extend the functionality surrounding these switches with e.g. custom options passed to the DevTools commands. As a result, we receive requests from developers to add more command line flags to expose such options.

We should consider replacing the exemplary life-cycle that headless_shell implements (setting sizes, waiting for page load, grabbing a screenshot, etc.) as a nodejs module (+ example app) that is more easily customizable to developers' needs. The C++ parts of headless_shell then no longer need to support exemplary command line options, such as --screenshot / --print-to-pdf / --dom-dump. Instead, an exemplary page load/life cycle that supports such functionality will be provided in the new nodejs module.
 

Comment 1 by bna...@gmail.com, May 9 2017

First, I'm looking for a way to replace wkhtmltopdf and wkhtmltoimage by chromium print-to-pdf and screenshot feature.

I still do not fully understand how communication with "headless" API.

I would be happy to have a shared library and some C/C++ headers to use headless API without being forced to download many gigabytes needed to compile chromium from the source code.



https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md#Usage-as-a-C_library


The library proposed here would use chrome's remote debugging protocol [1] via websockets to interact with headless chrome. That's the primary API surface for interacting with headless chrome (and doesn't require compiling chromium). See some examples for using this API in the context of headless here [2].

[1] https://chromedevtools.github.io/devtools-protocol/
[2] https://developers.google.com/web/updates/2017/04/headless-chrome#node
After Google I/O, DevRel would like to write up some recipes that use Node (possibly other languages) with the protocol to accomplish common tasks. I think there are a bunch of things we can show off, as well as community articles and samples.

eseckler@ feel free to ping if you have ideas on what to include.
#3: Cool! I think there's been a lot of attention around screenshots (particularly of the whole page) and pdf generation. Automated testing is probably another big one. Sounds like collecting such recipes / common tasks and maybe including them in the proposed library & app might be a good idea :)
Screenshots, definitely. For those following, screenshots using headless appear to be buggy atm: https://bugs.chromium.org/p/chromium/issues/detail?id=714058

Comment 6 by bna...@gmail.com, May 9 2017

An example written in Python for me would be of great help.
Components: Internals>Headless
It feels like with Puppeteer there no longer really a need for us to provide Node.js examples anymore. It would still be nice to trim down headless_shell a bit, but it's probably not that urgent anymore. Does that sound right?
Yeah, I agree. Puppeteer is practically said nodejs library :)
Status: WontFix (was: Available)
Agree here. And I imagine Eric's cool with this as well. 

I'll close.
OK, filed bug 767346 for the trimming down of headless_shell.
Yes, Puppeteer ftw!

Sign in to add a comment