Internet Explorer Driver

This driver has been tested with IE 6, 7, 8 and 9 on appropriate combinations of XP, Vista and Windows 7.

The driver supports running 32-bit and 64-bit versions of the browser, but the choice of how to determine which "bit-ness" to use in launching the browser is left to the language bindings. However, the general rule of thumb is that if the code that instantiates the driver is running in a 32-bit process, the 32-bit version of IE will be launched. Similarly, if the code intantiating the driver is in a 64-bit process, the 64-bit version of IE will be launched.

Installing

Simply add the selenium-server-standalone.jar to your CLASSPATH. You do not need to run an installer before using the InternetExplorerDriver, though some configuration is required.

Pros

• Runs in a real browser and supports Javascript

Cons

• Obviously the InternetExplorerDriver will only work on Windows!
• Comparatively slow (though still pretty snappy :)

Required Configuration

• On IE 7 or higher on Windows Vista or Windows 7, you must set the Protected Mode settings for each zone to be the same value. The value can be on or off, as long as it is the same for every zone. To set the Protected Mode settings, choose "Internet Options..." from the Tools menu, and click on the Security tab. For each zone, there will be a check box at the bottom of the tab labeled "Enable Protected Mode".
• The browser zoom level must be set to 100% so that the native mouse events can be set to the correct coordinates.

Native Events and Internet Explorer

As the InternetExplorerDriver is Windows-only, it attempts to use so-called "native", or OS-level events to perform mouse and keyboard operations in the browser. This is in contrast to using simulated JavaScript events for the same operations. The advantage of using native events is that it does not rely on the JavaScript sandbox, and it ensures proper JavaScript event propagation within the browser. However, there are currently some issues with mouse events when the IE browser window does not have focus, and when attempting to hover over elements.

Browser Focus

The challenge is that IE itself appears to not fully respect the Windows messages we send the IE browser window (WM_MOUSEDOWN and WM_MOUSEUP) if the window doesn't have the focus. Specifically, the element being clicked on will receive a focus window around it, but the click will not be processed by the element. Arguably, we shouldn't be sending messages at all; rather, we should be using the SendInput() API, but that API explicitly requires the window to have the focus. We have two conflicting goals with the WebDriver project.

First, we strive to emulate the user as closely as possible. This means using native events rather than simulating the events using JavaScript.

Second, we want to not require focus of the browser window being automated. This means that just forcing the browser window to the foreground is suboptimal.

An additional consideration is the possibility of multiple IE instances running under multiple WebDriver instances, which means any such "bring the window to the foreground" solution will have to be wrapped in some sort of synchronizing construct (mutex?) within the IE driver's C++ code. Even so, this code will still be subject to race conditions, if, for example, the user brings another window to the foreground between the driver bringing IE to the foreground and executing the native event.

The discussion around the requirements of the driver and how to prioritize these two conflicting goals is ongoing. The current prevailing wisdom is to prioritize the former over the latter, and document that your machine will be unavailable for other tasks when using the IE driver. However, that decision is far from finalized, and the code to implement it is likely to be rather complicated.

Hovering Over Elements

When you attempt to hover over elements, and your physical mouse cursor is within the boundaries of the IE browser window, the hover will not work. More specifically, the hover will appear to work for a fraction of a second, and then the element will revert back to its previous state. The prevailing theory why this occurs is that IE is doing hit-testing of some sort during its event loop, which causes it to respond to the physical mouse position when the physical cursor is within the window bounds. The WebDriver development team has been unable to discover a workaround for this behavior of IE.

Clicking <option> Elements and alert()

There is one place where the IE driver does not interact with elements using native events. This is in clicking <option> elements within a <select> element. Under normal circumstances, the IE driver calculates where to click based on the position and size of the element, typically as returned by the JavaScript getBoundingClientRect() method. However, for <option> elements, getBoundingClientRect() returns a rectangle with zero position and zero size. The IE driver handles this one scenario by using the click() Automation Atom, which essentially sets the .selected property of the element and simulates the onChange event in JavaScript. However, this means that if the onChange event of the <select> element contains JavaScript code that calls alert(), confirm() or prompt(), calling WebElement's click() method will hang until the modal dialog is manually dismissed. There is no known workaround for this behavior using only WebDriver code.

How InternetExplorerDriver Selects the IE Binary

This is done by the client side code. The client side checks to see if the OS is x64. If this succeeds then it checks that the process running the client side code is a 64-bit process. If that succeeds then the client code will try load the 64-bit version of Internet Explorer. If any of the checks for x64 fail the code will try use 32-bit version of Internet Explorer.

Multiple instances of InternetExplorerDriver

Unlike other WebDriver classes, there should only ever be a single InternetExplorerDriver instance at one time for some language bindings. If you need to run more than one instance of the InternetExplorerDriver at a time, consider using the Remote!WebDriver? and virtual machines.