Chromedriver/Chrome is pretty great at executing WebDriverJs scripts without taking away your focus (so you can execute them in the background whilst doing other things), the one exception I found was selecting items in a select list. I found it would do this:

Recently our WebDriver tests that run in Chrome via a Windows service all suddenly stopped working even though we hadn’t made any changes to our tests. It seems Chrome had automatically updated itself on our WebDriver agents introducing a Chromium 38 bug meaning WebDriver won’t work at all (full details here and here). Getting these tests running again has been very painful, mainly due to Google not having standalone Chrome installers for any previous versions of Chrome publicly available.

If you run any WebDriver tests I highly recommend you lock down your browser versions to stop this happening to you in the future. Here’s how:

Firefox

Firefox is fantastic in this regard as they make every back version easily accessible as well as a simple way on all platforms to stop automatic upgrades. I tend to lock down to Firefox ESRs (Extended Support Releases) such as versions 24 and 31 which are listed on this comprehensive Wikipedia page.

To stop updates all you do is open preferences, advanced, update and select ‘never’.

Chrome

Chrome is a P.I.T.A. in both being able to install a previous version or lock down the currently installed one. Google prefer a Chrome web installer which always installs the latest version of Chrome, and if you want a specific version you need the alternate (offline) installer (for all users if you use a Windows service), but they only provide the latest installer. It’s hard if not impossible to find older alternate (offline) installers on the web, even oldapps.com can’t host them.

Once you have a version of Chrome on Windows that you want to keep, you need to download a group policy template, and disable automatic updates before running Chrome (so it doesn’t automatically update before you set the group policy). I won’t go into full details but you should be able to find all details here. Some sites mention using a plugin to stop updates but this doesn’t work so you’ll need to go down the group policy path.

A colleague contacted me today to see if there’s a way to increase the speed of a text_field.set operation in watir-webdriver when using Chrome on Mac OSX. I hadn’t noticed it before but Chrome seems to enter character by character into text fields which is noticeably slower than Firefox which seems to ‘set’ the field at once. Jari Bakken suggested I try Chrome native events which I didn’t even realize existed on Mac OSX.

So, I took Jari’s suggestion and I created a benchmark of a .set operation conducted ten times in a row on Firefox, and Chrome with and without native events. The results looked like:

You can see that Chrome is drastically slower than Firefox in setting text fields, but native events does seem to provide a roughly 25% speed improvement. I think I will stick to running my watir-webdriver tests against Firefox unless specifically needed.

I recently found the need to ignore certificate errors when running Watir-Webdriver tests in Google Chrome. The way to do this is slightly different from doing it in Firefox. Unlike Firefox where you create capabilities and profiles, in Google Chrome you pass arguments to Chrome to enable/disable certain browser features.

For example: to ignore certificate errors, disable pop-ups, disable translate and specify a proxy you do:

I’ve been trying to get Watir-WebDriver to use a proxy for both http and https sites, but was having a bit of trouble.
There are a couple of key pointers: you need to specify the proxy address without the ‘http://&#8217; prefix (or it’ll crash), and you need to also specify a :ssl parameter to Firefox profile.