Is there an equivalent of this for C#? I use Selenium a lot and find it annoying. Be interested to see if this is much better.
Puppeteer: Headless Chrome Node API
21–30 of 105 posts
Re: Puppeteer: Headless Chrome Node API
#22So 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?
Based on a quick read of the API, my interpretation is that this is not targeting people who are trying to automate every browser, but those who need to automate any browser.
In that context, it's dead-simple to use, and someone with very little experience should be able to get a working prototype in under 5 minutes.
For my use case, it's closer to "wget/curl with JS processing" than "automating a user's browsing experience". I don't particularly care which browser is doing the emulation, with the ease-of-use of the API making the biggest difference.
It seems very similar to PhantomJS, but to be honest, it's more attractive from an ongoing-support standpoint simply because it's an official Chrome project.
Re: Puppeteer: Headless Chrome Node API
#23Very cool. In a previous job we ran our JS unit tests on PhantomJS, using a tool that allowed arbitrary code to be piped to Phantom for execution and redirected Phantom's console to stdout. (We did all this so our tests ran on something resembling a real browser, as opposed to jsdom.) Something similar should be possible with this.
Re: Puppeteer: Headless Chrome Node API
#24Pretty psyched to see this. A lot of my automated testing headaches came from the intersection of using PhantomJS with transpiled code - which makes sense, since the Phantom team was always forced to play catch-up with the browsers being emulated.
Re: Puppeteer: Headless Chrome Node API
#25Has headless Chrome enabled file downloads yet? (I don't mean navigating to a known url and saving content, but when a site pops open a save dialog)
Re: Puppeteer: Headless Chrome Node API
#26Has anyone found something similar but for Python? The few I found all seemed to be abandoned or too limited in capability.
Re: Puppeteer: Headless Chrome Node API
#27I think simple-headless-chrome is more far along https://github.com/LucianoGanga/simple-headless-chrome
We're fans of LucianoGanga's project (and of Chromeless, Doffy, Chrominator, Chromy, Navalia). I can tell you from personal experience that dealing with the raw DevTools Protocol isn't ideal for a developer writing an automation script, so it's clear there's demand for libraries with this higher-level API. Would love to know if there's a feature parity concern you have or what you'd like to see from puppeteer (or any…
Chromeless allows for the setting of cookies. I noticed in an issue for Puppeteer that it wasn't seen as a high priority. Our use-case (session based cookies) rely on a cookie being set in order for our PDF screenshots to work.
Any chance you could give us some insight on when this may be available?
Re: Puppeteer: Headless Chrome Node API
#28So 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?
I think this can be ok. It's pretty obvious that the Webdriver protocol was insufficient. Let browsers "take it home" for remodelling and see if a new standardization effort will happen down the line.
Re: Puppeteer: Headless Chrome Node API
#29This is really nice. Thanks for your work.
Re: Puppeteer: Headless Chrome Node API
#30Would be nice if it was possible to change the proxy settings for each request or for each session. Last time I checked it was only possible with the C API.