I think you've given my weekend some purpose. Lemme see what I can pull together...
I just got it working like this:
apt install chromium-chromedriver
chromedriver
This seems to create a service that listens on port 9515 for standardized commands to remote control a chromium instance. The commands seem to be specified by the W3C:https://www.w3.org/TR/webdriver/
I got it to open a browser with this curl command:
curl -d '{ "desiredCapabilities": { "caps": { "nativeEvents": false, "browserName": "chrome", "version": "", "platform": "ANY" } } }' http://localhost:9515/session
I have not yet figured out how to send javascript commands though. apt install chromedriver
gives me: Package 'chromedriver' has no installation candidate
There is something called "chromium-chromedriver".Let me try that ... one moment ...
Ok. So I start it via:
apt install chromium-chromedriver
Now according to the docs, this should create a browser: curl -d '{ "desiredCapabilities": { "caps": { "nativeEvents": false, "browserName": "chrome", "version": "", "platform": "ANY" } } }' http://localhost:9515/session
Ha! It works!So chromedriver might be a solution!
The CLI interface is somewhat incomplete as-of-now, but it'd be fairly easy to add more comprehensive tools.
It’s very much like that already: write script, send to browser, let it do it’s thing, run javascript code if you want and get the final renderend HTML and console output.
What would you do with this solution
Automate the browser that can’t already be done
I did not say it can't be done now. But I don't want the overhead of pupeteer, selenium plus the client libraries to control them. These things are fricking monsters. And they will go out of fashion at some point. Simple javascript commands will not. with headless browsers
I don't want headless. I just want to automate.I don't understand this objection. Puppeteer is the client library that you want, and it's not particularly massive. It's the plumbing to handle all of the stuff around starting and connecting to browsers, providing a tidy API to abstract the stuff that's annoying to use directly.
In fact, you can do almost anything you want to using the existing interface that Chrome has built in:
chromium --remote-debugging-port=9222
You can connect to it using e.g. the WS command line tool using the URL it spits out: ws ws://127.0.0.1:9222/devtools/browser/81b9b178-ece0-4953-8ea0-bce6ac31d89c
Then you can make it do things: {"id": 1, "method": "Target.createTarget", "params": {"url": "http://www.google.com"}}
It does what you want, over a web socket interface rather than HTTP.Where does that ws tool come from? Is it this one? https://packages.debian.org/stretch/node-ws
How do you send javascript commands over that protocol?
You can also just start chromium with debugging active `--remote-debugging-port=9222` and then connect to that port and send any dev console commands.
Looks like it's a REST protocol.
You have to connect to a tab and then call e.g.
Runtime.evaluate {expression: "console.log('test')"}Won't be surprised if an extension like this already exists.
That would be all I need to satisfy all my browser automation tasks.
Without installing and learning any frameworks.
Say there was a linux command 'SendToChromium' that would do that for Chromium. Then to navigate to some page one could simply do this:
SendToChromium location.href="/somepage.html"
SendToChromium should return the output of the command. So to get the html of the current page, one would simply do:
SendToChromium document.body.innerHTML > theBody.html
Ideally the browser would listen for this type of command on a local port. So instead of needing a binary 'SendToChromium' one could simply start Chromium in listening mode:
chromium --listen 12345
And then talk to it via http:
curl 127.0.0.1:12345/execute?command=location.href="/somepage.html"