4 ms·

I wrote a little ipython notebook with a stupid simple example of getting headless chrome up and talking to it via a websocket: https://gist.github.com/llimllib

I wrote a little ipython notebook with a stupid simple example of getting headless chrome up and talking to it via a websocket: https://gist.github.com/llimllib/7f6143a1a6955d243161b2fec23b8f4d https://gist.github.com/llimllib/7f6143a1a6955d243161b2fec23... Then I started on a python library that would handle communication with chrome in a real way using asyncio: https://twitter.com/llimllib/status/855433309375082496 https://twitter.com/llimllib/status/855433309375082496 If that's a thing that you're interested in, let me know. https://github.com/llimllib/chrome-control/tree/wstest https://github.com/llimllib/chrome-control/tree/wstest

fake-name 9y ago
FWIW, I wrote a wrapper that exposes the remote debugger interface in python functions here: https://github.com/fake-name/ChromeController https://github.com/fake-name/ChromeController It works by reading the interface descripton JSON files, and dynamically generating the API. It doesn't handle the higher-level stuff (async, etc...), but for synchronous things, it's quite nice. -------- As an aside, if you're interested in this sort of thing, the chrome devtools protocol has a issue tracker here: https://github.com/ChromeDevTools/devtools-protocol/issues https://github.com/ChromeDevTools/devtools-protocol/issues Yes, it's on github, no idea why, when they already have their monorail issue tracker.
- ebidel 9y ago
  FWIW, we created the Github issue tracker b/c it's a bit more approachable for everyone. Github is also a much better place for discussions.
  - fake-name 9y ago
    Ah, that makes sense. Monowall is kind of poor. The inability to edit comments is particularly annoying.
- llimllib 9y ago
  I saw that! And it was helpful to me getting started, thanks. I wanted to generate types from the protocol file rather than generate them at run-time, so that was the first thing I did. I think it helps debuggability/autocompletability/readability to have the types reified; check it out if you're interested, all the capital-letter-named files are generated.
  - fake-name 9y ago
    It's a few-line change to output the AST to code via astor (it's actually part of how I got everything working in the first place). You get full executable code with docstrings an everything, though no support for generating inline comments (I think that changed in 3.6, IIRC). Would you be interested in a patch that does something like that? It should be a heck of a lot more robust then what you're currently doing (which is manual code generation?). ------ Also, if you're interested in doing things with the debug protocol, https://github.com/ChromeDevTools/devtools-protocol/issues/6 https://github.com/ChromeDevTools/devtools-protocol/issues/6 might be relevant. It's an issue about how there's no good way to determine the remote debug interface version, since the version information that's present never changes, and they keep moving functions.
    - llimllib 9y ago
      Definitely! And yeah the ad hoc protocol thing is... suboptimal
      - fake-name 9y ago
        I put together a caching system so the generated wrapper is made available for overview/manual-patching, etc.... It currently validates the generated file against a generated-from-the-json file at import, and falls back to blindly importing the json file if the tooling to generate the class definition is not available. Ideally, any patching for the class file should really be done as a subclass, as well as any more complex logic. That way, if the protocol json file is changed, it can be just updated without breaking anything. Anyways, generated class is here: https://github.com/fake-name/ChromeController/blob/master/ChromeController/Generator/Generated.py https://github.com/fake-name/ChromeController/blob/master/Ch... Oh, as an aside, you're actually missing a significant chunk of the protocol json file, mainly because there are actually two of them. There's a `browser_protocol.json` AND a `browser_protocol.json` file. They're both produced as build artifacts, so I can't point to them in the source, but the total json size should be > 800KB (mirror in chromecontroller: https://github.com/fake-name/ChromeController/tree/master/ChromeController/protocols https://github.com/fake-name/ChromeController/tree/master/Ch... ). As it is, this should kind of just splat into your source tree, but I don't want to move everything around without at least asking you how you want things structured.

fake-name 9y ago

FWIW, I wrote a wrapper that exposes the remote debugger interface in python functions here: https://github.com/fake-name/ChromeController https://github.com/fake-name/ChromeController It works by reading the interface descripton JSON files, and dynamically generating the API. It doesn't handle the higher-level stuff (async, etc...), but for synchronous things, it's quite nice. -------- As an aside, if you're interested in this sort of thing, the chrome devtools protocol has a issue tracker here: https://github.com/ChromeDevTools/devtools-protocol/issues https://github.com/ChromeDevTools/devtools-protocol/issues Yes, it's on github, no idea why, when they already have their monorail issue tracker.

ebidel 9y ago
FWIW, we created the Github issue tracker b/c it's a bit more approachable for everyone. Github is also a much better place for discussions.
- fake-name 9y ago
  Ah, that makes sense. Monowall is kind of poor. The inability to edit comments is particularly annoying.
llimllib 9y ago
I saw that! And it was helpful to me getting started, thanks. I wanted to generate types from the protocol file rather than generate them at run-time, so that was the first thing I did. I think it helps debuggability/autocompletability/readability to have the types reified; check it out if you're interested, all the capital-letter-named files are generated.
- fake-name 9y ago
  It's a few-line change to output the AST to code via astor (it's actually part of how I got everything working in the first place). You get full executable code with docstrings an everything, though no support for generating inline comments (I think that changed in 3.6, IIRC). Would you be interested in a patch that does something like that? It should be a heck of a lot more robust then what you're currently doing (which is manual code generation?). ------ Also, if you're interested in doing things with the debug protocol, https://github.com/ChromeDevTools/devtools-protocol/issues/6 https://github.com/ChromeDevTools/devtools-protocol/issues/6 might be relevant. It's an issue about how there's no good way to determine the remote debug interface version, since the version information that's present never changes, and they keep moving functions.
  - llimllib 9y ago
    Definitely! And yeah the ad hoc protocol thing is... suboptimal
    - fake-name 9y ago
      I put together a caching system so the generated wrapper is made available for overview/manual-patching, etc.... It currently validates the generated file against a generated-from-the-json file at import, and falls back to blindly importing the json file if the tooling to generate the class definition is not available. Ideally, any patching for the class file should really be done as a subclass, as well as any more complex logic. That way, if the protocol json file is changed, it can be just updated without breaking anything. Anyways, generated class is here: https://github.com/fake-name/ChromeController/blob/master/ChromeController/Generator/Generated.py https://github.com/fake-name/ChromeController/blob/master/Ch... Oh, as an aside, you're actually missing a significant chunk of the protocol json file, mainly because there are actually two of them. There's a `browser_protocol.json` AND a `browser_protocol.json` file. They're both produced as build artifacts, so I can't point to them in the source, but the total json size should be > 800KB (mirror in chromecontroller: https://github.com/fake-name/ChromeController/tree/master/ChromeController/protocols https://github.com/fake-name/ChromeController/tree/master/Ch... ). As it is, this should kind of just splat into your source tree, but I don't want to move everything around without at least asking you how you want things structured.