Using chrome debugger api features from Java sdk

[Binod Pant]

When using the Java SDK, once I got past the point of connecting to a browser instance, and getting its URL etc, I got lost, and could not find a way to actually start exercising the debugger extension api features like navigation messages etc.

How do I go beyond the

WipBrowserTab? tab = browser.getTabs(backend).get(<choose your tab>).attach(listener); JavascriptVm? javascriptVm = tab.getJavascriptVm()

lines and actually start sending messages such as navigation etc to the browser? I tried to follow along the code, and all I could find was some message classes, but I did not see a documented way of using the debugger extension api methods.

What I am trying to do is build up a temporary Webdriver implementation for Chromium Embedded browser that my dev team is using, that I can use until the Webdriver full support for CEF is available, even with minimal features like load pages, find elements etc.

Thanks

[Binod Pant]

To make my question more concrete,

if I am looking at a page like this that lists the capabilities of the debugger,

https://developers.google.com/chrome-developer-tools/docs/protocol/1.0/dom

Is there a way for me to (even with some additional work) expose these features in Java, for use with a Chromium embedded browser? I realize I may be duplicating some effort with what you or the CEF/Webdriver teams are already going to do, but I want to build something up as a demonstration that this can be done, and eventually hope to start using the full Java support in Webdriver/CEF when it becomes available.

Thanks

[Peter Rybin]

Hi Binod

1. Java SDK is a Java client for the protocol you are mentioning. As such it only covers Debugger part (domain) of it (plus Runtime). If you need to access other domains, you probably can locally modify the code and add your part. SDK basically does 2 things: internally deals with raw protocol messages and provides convenient public Java objects around them. Internal part is mostly automated: protocol interfaces are pre-generated and put in source base ('src-wip-generated' subdirectory inside plugin), with their implementation generated on the run; the following domains are already supported internally: "Debugger", "Runtime", "Page", "Network", "Console", "DOM", others can be easily added. The SDK does not make protocol interfaces public, instead you will have to make some kind of public interface to them.

We can discuss it more closely here, should you suggest a small example of what you want.

2. A remark about protocol. The debugger protocol is not a playback protocol. It was designed for pausing execution and manually inspecting artifacts. It was not designed to directly operate browser page. You probably can do a lot via 'evaluate' command, but still.

Please, let me know whether this was helpful and correctly address what you were asking about.

Peter

четверг, 3 января 2013 г., 0:58:32 UTC+4 пользователь Binod Pant написал:

[Binod Pant]

Thanks for the explanation Peter.

My core objective is to drive CEF windows using the Webdriver api. Given that the Webdriver support is not ready yet, I was hoping that this api layer would act as an alternative method for me to plugin directly to the "ChromeDriver" Java api that Selenium provides.

Here is what I do now

ChromeDriver Java api -- REST calls --> Chromedriver -- automation proxy --> Chrome


I was hoping this api would help me create this

ChromeDriver Java api -- REST calls --> Chromedriver Modified -- ThisLayer --> ChromeEmbedded(CEF)


or if getting this working involves too much work,  perhaps even bypass the ChromeDriver api, and do something like

Our custom Java api -- ThisLayer --> ChromeEmbedded(CEF)



Are either of these options feasible with the given state of the api? I believe approach 1 above is roughly a simplistic view of what Webdriver support for CEF will look like, and looks like a lot of work too.

Approach 2 would be great if it supported even just the basic capabilities what webdriver provides. We have an api layer that sits on top of Webdriver, so we have the capability to switch underneath to use something other than Webdriver if we have to. But ideally Webdriver api usage would be ideal and is where we want to be long term.


Hope this clarifies my question further.

Thanks

[Ken Kania]

Hello.  I'm working on the new version of ChromeDriver that also uses the DevTools framework.  You can see the code here:  http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/chromedriver/

The options you mention should be feasible with the Java SDK, but it'd require some local changes (as Peter mentions).

Alternatively, if you're comfortable with C++, we'd welcome patches to the code we've started.  We're about a week or so away from being able to do the basic things you mention above (load page, find elements, etc.), although it's still a bit rough around the edges.  You can see http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/chromedriver/README.txt?view=markup to help you get started (once you've checked out the chromium code successfully).

Ken

[Binod Pant]

That's great to hear Ken. Thanks for your reply. I will take a look at the code. Just another question. Assuming this chromedriver is available, what other pieces will have to be done on the CEF side (if any) to enable full usage with CEF? Perhaps this question is more relevant on the CEF forum but since I am interested in CEF for the time being, it would be nice to get some sense of any additional work on that side of things, if needed. As far as I understand, chrome itself starts with the automation pieces built in so chromedriver can talk to it. Will the same be the case for CEF or are there additional hooks to be added to CEF to enable automation with chromedriver ?

Regards,
-Binod

[Ken Kania]

Yes, I'm not sure how CEF works.  You just need to make sure they're starting the remote debugger.  You'll have to tweak ChromeDriver (locally) to connect to the remote debugger inside CEF instead of Chrome.

Ken

[Binod Pant]

Just checking back on this. For the last couple of weeks since we had this dicussion, I have been trying to get to build CEF and chromedriver locally.

I have been able to build CEF locally and use the packaged sample cefclient application to try stuff (thanks to Marshall for this expedient help there). I have been using the release 25.x and a release build of CEF3, but I feel confident to do this with trunk as well.

Now I need to understand how chromedriver (devtools based) works and try and build that locally too. Reading up on chromium instructions, it looks like I am basically setup to build chromium. The question is, do I need to build the entire chromium src tree (that looks like hours long), or is there a quicker way to just build chromedriver for quicker development cycle? I am not really needing to rebuild chrome here, I have a local build of my browser (CEF in this case).

Are there steps specific to building chromedriver that will make it go faster, esp in light of the fact that I may be working on the cefclient and chromedriver builds simultaneously?

As for your comment about looking into CEF/automation: Peter please fill me in if I miss important points, but it looks like it I start up the CEFclient application on windows, devtools 'just works', as long as I specify the debugger port to CefSettings. With that one change, devtools is able to talk to my CEF application. The question now is, how do I drive this application with chromedriver (and hopefully using the same Chrome client in Java that I use to drive chrome right now)

Any suggestions on next steps? I don't want to get lost in the huge chromium dev cycle, and yet be able to try chromedriver (devtools edition) with CEF.

Thanks

[Binod Pant]

Sorry for not reading through our previous post carefully. I realized that for the building part, you have already posted the link to instructions. I will try building with the instructions in your link. 

As for my observation that simply providing a debugger port to CefSettings was enabling interaction from devtools, I have a feeling if I do the step "You'll have to tweak ChromeDriver (locally) to connect to the remote debugger inside CEF instead of Chrome." that you proposed, it should be enough for basic interaction hookup. Perhaps that is the direction to take now. Still, I will need to build chromedriver locally to be able to do this, so I am on to building chromedriver now!

Now I wish I could almost have the CEF forum and this forum inter-linked so we could get Marshall's feedback too!

[Ken Kania]

Alright, let me know if you run into any trouble (you can contact me directly).  The DevTools-based chromedriver should be simple to build.  Although you need a standard checkout of the chromium source tree, it should only take a few minutes to build.

Ken

--
You received this message because you are subscribed to the Google Groups "chromedevtools-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromedevtools-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Binod Pant]

Thanks. Before I went ahead and tried this, I did want to circle back on the response I got from the CEF forum.

Quoting from http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=1442&p=15630#p15630 

"CEF3 supports devtools remote debugging but perhaps not any extensions to the devtools protocol. See http://code.google.com/p/chromiumembedd ... ail?id=549 for more information."

Would this entail any problems you can see, or should this be okay? I am not sure what 'extensions to devtools protocol' are.

To unsubscribe from this group and stop receiving emails from it, send an email to chromedevtools-dev+unsub...@googlegroups.com.

[Ken Kania]

The extensions are new additions to the protocol (currently not released) that allow for stuff like simulating mouse/key input.  Most of these are implemented in WebKit and so will be picked up automatically in CEF.  A few are not.  One thing that comes to mind is handling modal dialogs, which will probably require minor changes in CEF itself.

To unsubscribe from this group and stop receiving emails from it, send an email to chromedevtools-...@googlegroups.com.

[Binod Pant]

Hello Ken

I am reading through the chromedriver code, and to your point about "You'll have to tweak ChromeDriver (locally) to connect to the remote debugger inside CEF instead of Chrome.", here is what I think would need to be done. Please fill me in or point me in the right direction


It looks like Webdriver uses a NamedProxyLauncher subclass of ProxyLauncher that allows connection to a running browser, I see the following in

 if (channel_id.empty()) {
   // other stuff
    logger_.Log(kInfoLogLevel, "Launching chrome: " + command_line_str);
    launcher_.reset(new WebDriverAnonymousProxyLauncher());
  } else {
    logger_.Log(kInfoLogLevel, "Using named testing interface");
    launcher_.reset(new WebDriverNamedProxyLauncher(
        channel_id, launch_browser));
  }


This seems to indicate that by specifying a channelid, and by specifying launch_browser_=false, I can make it use a NamedProxyLauncher that does not launch a browser but connects to an existing IPC channel.

I see this in use by src\chrome\test\ui\ui_test.cc for example

It looks like there are settings that will enable connecting to a running browser process.

Could this technique be used with CEF? If so, how would I get the channel id for running CEF instance in the first place (will it be different based on the application that launches the CEF instance)? I will continue reading through, but it might be faster if you point me in the right direction. I was not sure where to start.

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to chromedevtools-dev+unsub...@googlegroups.com.

[Ken Kania]

You're looking in the wrong place unfortunately.  That's the old version of ChromeDriver!  The new code is under chrome/test/chromedriver.  See chrome_impl.cc there for a start.

To unsubscribe from this group and stop receiving emails from it, send an email to chromedevtools-...@googlegroups.com.

[Binod Pant]

Got it, thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to chromedevtools-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Binod Pant]

Another question as I am trying a custom build of chromedriver.exe . I have made some local changes and would like to generate a chromedriver.exe to try it out.

I can buidl the 'chromedriver2' module and generate the chromedriver2.dll just fine, but how do I generate the chromedriver.exe with my changes? It looks like if I link 'chromedriver' module it generates the exe but it still uses the chromedriver.dll. Do I have to use any tricks like renaming the chromedriver2.dll to chromedriver.dll, or is there a better way?

Thanks! 

[Ken Kania]

Try building chromedriver2_server. That should generate
chromedriver2_server.exe, which you can rename.

>>>>>> an email to chromedevtools-...@googlegroups.com.

>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "chromedevtools-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>> an email to chromedevtools-...@googlegroups.com.

>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>
>>>
> --
> You received this message because you are subscribed to the Google Groups
> "chromedevtools-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to chromedevtools-...@googlegroups.com.

[Binod Pant]

Oh I must have the older build then, since i used the CEF process to get a release build of chromium. I do not see a chromedriver_server project in my solution. I will sync trunk and try again.

Thanks

You received this message because you are subscribed to a topic in the Google Groups "chromedevtools-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chromedevtools-dev/cFls6VPp2cY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to chromedevtools-...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
-Binod
"Life is beautiful, just open your eyes"

[H Wolfe]

Ack I must have the old version too