Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Puppeteer: Headless Chrome Node API

github.com

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Puppeteer: Headless Chrome Node API

#52

Post by Garbee »

borplk wrote: post #47

Does anyone know if it's possible to take a screenshot of a specific DOM element? (instead of the entire page)

Currently only PDF printing of the entire page view-port is available. File an issue with your use-case so the team can assess whether or not to look into including that kind of behavior.

Re: Puppeteer: Headless Chrome Node API

#54

Post by fake-name »

tholman wrote: post #12

One of the biggest wins here is this little tidbit: > When you install Puppeteer, it downloads a recent version of Chromium (~71Mb Mac, ~90Mb Linux, ~110Mb Win) that is guaranteed to work with the API. A lot of the chrome interface libs about at the moment require you to maintain your own instance of chrome/chromium and launch the headless server with your command line, or require a pre compiled version, that can qui…

There is complexity here you may not be seeing, namely if you are on a platform without X, it will not work.

Normal chromium requires a bunch of X libraries be present. It doesn't use them, but for things like headless testing, it's a massive pain, since the apt-get (or equivalent) is generally many hundreds of megabytes.

Re: Puppeteer: Headless Chrome Node API

#57

Post by fake-name »

auchenberg wrote: post #11
bauerd wrote: post #9

So first there was Selenium's JSON Wire protocol, then came the W3C WebDriver spec and now we're back to browser-specific implementations? As someone who's tried/is trying to automate Firefox/Chrome/Safari/IE in a consistent fashion, my only question is: WHY?

Chrome DevTools Protocol (CDP) is a more advanced API, and I've been leading an effort on getting multiple browsers to look at CDP under https://remotedebug.org

Get them to actually version their protocol first, maybe?

As someone with a bunch of tooling around the dev-tools API, it's a huge pain in the ass to not be able to tell what functions the remote browser supports. There's a version number in the protocol description, but it's literally never been incremented as far as I've seen.

https://github.com/ChromeDevTools/devtools-protocol/issues/6

Re: Puppeteer: Headless Chrome Node API

#58

Post by fake-name »

bauerd wrote: post #17
d33 wrote: post #10

Earlier quoted context omitted.

Because WebDriver just doesn't do. For an example of an impossible task, try to retrieve request headers using Selenium. Browser automation getting more and more complicated the more cases you're trying to cover and in my impression WebDriver is definitely not enough. Who knows, perhaps some new version of WebDriver that I never heard of it will catch up once the functionality gets properly defined.

Yes, I wholeheartedly agree, it was a stupid decision by the Selenium devs not to make request headers etc. accessible. But why throw all the standardisation efforts overboard?

I think this is more "selenium is actively antagonistic to it's major use-case", then trying to throw everything away. There have been multiple attempts to convince the selenium people to revisit their decision W.R.T. headers, and they're completely unwilling.

Given that the selenium leadership is apparently uninterested in improvements, and it's many limitations, trying to improve there is more effort then it's worth.

Re: Puppeteer: Headless Chrome Node API

#60

Post by brlewis »

cestith wrote: post #33

I'm a little concerned about the confusion in the market of another product in the automation space called "Puppet"-something. The project itself looks exciting.

I can imagine using Chrome Puppeteer in conjunction with Google Puppeteer https://github.com/google/puppeteer

The latter having been renamed from "puppet" when Google open-sourced it.

Post reply on HN