WebDriver: The Master Plan

I posted this to the WebDriver group today, and thought that it might benefit from a slightly wider audience. So, that'll be the four of you who read this blog, then!

I thought it may be useful to give a bit of a run-down on my current list of ideas and issues to do with WebDriver, so that people know what's coming and what I'm planning to work on. It's a bit of a ramble, and may be missing technical context in places, so if this isn't your sort of thing, please skip this post :)

Problem: Javascript Alerts and Prompts

Solution: This is pretty easy to do in IE (spawn a separate thread that watches out for alerts being opened and tieing them to an open IE instance) but a bit tricky in Firefox. To get the API I want, it would be useful to be able to make Firefox "sleep". Sadly, there's no primitive to do this in JS, but there's still some possibilities.

Problem: Native events for Firefox

Solution: I need to find a mechanism for determining the HWND associated with an HTML document in Windows. I also need to learn a little about X for UNIX. How hard can it be?

Problem: The Safari driver needs a lot of TLC

Solution: I'm planning on taking a leaf out of the Gears book, and implementing an Input Manager hack to get access to Safari. This means that we may encounter some rough weather when Snow Leopard is released, and that it will be Mac OS only. On the plus side, I know that it can made to work, and already have some sample code that reaches into the DOM of a page (kindly donated by a friend in Australia)

Problem: The Chrome driver isn't done

Solution: Someone's working on this, and I'm talking to him to try and get the code available. As soon as I can, it'll be there. FWIW, it looks like we'll be going in through the automation interfaces used by Chrome's own unit tests.

Problem: Selenium emulation isn't complete

Solution: This partly hinges on the "js alerts and prompts" problem, but also hangs on modularising Selenium Core and injecting it where that's the appropriate thing to do (because Selenium's pretty huge, and injecting the whole thing every time we wanted to emulate a method would be dumb) I plan to do this by reading the source of Core via Rhino and then outputting various functions into files. This allows us to automatically generate the modules of Core, which makes tracking HEAD of Selenium a lot easier.

Problem: Bindings for other languages (C#, Python and Ruby)

Solution: The reworking of the IE driver that's going on in the "dotnet_bindings" branch will facilitate writing bindings for IE (using ctypes, DL, pinvoke or JNA) The Firefox driver is a SMOP (Simple Matter of Programming) because the wire protocol is pretty easy. Remote support should be easy to write too, once I finish documenting the protocol (and implementing it properly) There are some nascent Python bindings which people are working on, and I'm using the .Net bindings for IE to rework the IE codebase. There are some ruby versions of webdriver on github too, which is great to see!

Problem: The IE driver crashes

Solution: We're working on making sure that the only exceptions that occur in the IE driver are things that are beyond our control. We're pushing more defensive checks into the codebase to stop some of the dafter mistakes and releases will be made with try/catch blocks and handling of runtime exceptions turned on. We may get some grotty behaviour, but it should never take down the JVM again.

Problem: The IE driver doesn't support 64bit

Solution: This is being worked on now!

That's the major list of issues that are occupying my thoughts right now. If anyone's interested in chipping in and getting involved, or just getting some more information on any of these points, please feel free to either ping me an email or ask about it on the list.


Simon Stewart on Tuesday, 06 January, 2009

Posted in: /tech/webdriver

You may comment...



Added by Sangeetha Kandel on Wednesday, 27 January, 2010

Any plans of extending the support for PHP?

Categories