Examples of CDP with interactive pages

[zfLQ2qx2]

Can someone point me to some examples of using the cdp package with an interactive web page? I see a lot of examples of loading a page and querying the DOM, but nothing covering how to move the mouse, click elements, tap elements, fill a form, attach a file to a form, interact with dialogs and subwindows, etc.

[mafredri]

Hi @zfLQ2qx2, the protocol does allow you to do most of these things but it is quite low-level and some functionality can only be achieved by evaluating JavaScript on the page. I'm a bit short on examples, but I have another project, asdev, that uses cdp to perform some of these things, e.g. submit forms, attach files and click buttons. Feel free to look there for inspiration.

To perform actual mouse clicks, you would use the protocol to figure out the position of an element and then use e.g. Input.DispatchMouseEvent to move the mouse or perform the press (e.g. two events, first of type mousePressed, second of type mouseReleased).

There are also some examples in the chrome-remote-interface Wiki (e.g. wait for a specific element). These are in JS but should be fairly simple to translate to Go/cdp.

Regarding sub-windows, you might have to keep track of frames (see frame related events in Page domain) but I'm not sure as I haven't done this myself. I recommend checking out some of the resources, especially the Chrome DevTools Protocol repo and mailing list.

Hope this helps!

[zfLQ2qx2]

@mafredri That is exactly what I was looking for, thank you!

[zfLQ2qx2]

@mafredri I've made some progress on this, I can detect windows being opened via TargetCreated events. The TargetCreated reply includes a TargetID. Is it correct that in order to interact with this new window I would need to lookup its url from the debugger /json/list URL, open an additional websocket, and create an additional cdp client?

[mafredri]

It's not necessary to use /json/list if you know the address/port and the target ID. The websocket URL can be constructed: fmt.Sprintf("ws://%s:%s/devtools/page/%s", browserIP, port, targetID).

It's also possible to utilize the existing websocket with target.AttachToTarget and target.SendMessageToTarget/target.ReceivedMessageFromTarget (for communication). I'm working on a package (and small changes) to make working with this more seamless. There's some discussion about it in #33 (and #10).

For now it's probably easiest to open up a new websocket (and client).

[zfLQ2qx2]

Just for the benefit of anyone who reads this later, I saw a gist elsewhere where someone recommended using Target.SetAutoAttach to attach to new instances and make them wait for a debugger to attach, when a new target opens we would then open a new cdp connection to it, put all of the event handlers in place for it, then do Runtime.RunIfWaitingForDebugger to put the new target in motion.