1
votes

I've replicated this Watir Webdriver problem in Ruby 1.9.2 with IE8 and 1.9.3 with IE9; it does not seem to happen if I use Chrome or Firefox. The OS is Windows 7 (64 bit).

When I use Watir Webdriver to click certain links, the action completes successfully (in that the browser goes to the href of the link) but it looks as though the click event keeps on firing for ever. This is most obvious in cases where mousing over the link causes a drop-down menu to appear: after the link is clicked, the drop-down remains visible until the browser is closed (providing of course you are looking at a page that contains that link).

The real showstopper for me is that once this has happened, I can't click any other links. The only way I have found to get IE back into a normal state is to close and re-open the browser.

An example:

require 'rubygems'
require 'watir-webdriver'
include Watir
b=Browser.new :ie
# This produces the following output:
# Started InternetExplorerDriver server (64-bit)
# 2.28.0.0
# Listening on port 5555
# => #<Watir::Browser:0x..fe85636c0 url="http://localhost:5555/" title="WebDriver">

b.goto 'www.net-a-porter.com'
b.link(:text,'Designers').click

At this point, IE shows the page I would expect (http://www.net-a-porter.com/Shop/AZDesigners) but the Designers drop-down is still visible, which it shouldn't be, and href of the original link still shows in IE's status bar.

At first I assumed it was a bug with this specific website, but a similar thing happens on yahoo.com, using the following code:

b.goto 'www.yahoo.com'
b.link(:text,'Sport').click

The Yahoo! Sport page loads, but the URL keeps flickering in the status bar and the "Football" drop-down menu is appearing. Here's a screenshot to show you whar I mean:

Screenshot showing drop-down still visible after navigation has completed

Now, when I resized the browser to take that screenshot, I noticed different menus appeared as the margins reduced and content shifted to the left to fit into the smaller space available. So it seems there is a stray mouse click that keeps repeating in the same location.

Could this be a bug in Watir Webdriver or Selenium perhaps?

Here's my gem list:

  • addressable (2.3.2)
  • builder (3.1.4)
  • bundler (1.2.3)
  • childprocess (0.3.6)
  • coderay (1.0.8)
  • columnize (0.3.6)
  • commonwatir (4.0.0, 2.0.4)
  • cucumber (1.2.1)
  • debugger (1.2.3, 1.2.2)
  • debugger-linecache (1.1.2)
  • debugger-ruby_core_source (1.1.6, 1.1.5)
  • diff-lcs (1.1.3)
  • differ (0.1.2)
  • ffi (1.2.0 x86-mingw32)
  • gherkin (2.11.5 x86-mingw32)
  • highline (1.6.15)
  • hoe (3.4.0)
  • hpricot (0.8.6)
  • json (1.7.6, 1.7.5)
  • libwebsocket (0.1.7.1)
  • logger (1.2.8)
  • method_source (0.8.1)
  • mini_magick (3.4, 3.2.1)
  • minitest (4.3.3, 1.6.0)
  • multi_json (1.5.0)
  • mysql2 (0.3.11 x86-mingw32)
  • nokogiri (1.5.6 x86-mingw32)
  • pg (0.14.1 x86-mingw32)
  • pry (0.9.10 i386-mingw32)
  • pry-doc (0.4.4)
  • rake (10.0.3, 0.8.7)
  • rautomation (0.8.0, 0.7.3, 0.6.3)
  • rbx-require-relative (0.0.9)
  • rdoc (3.12, 2.5.8)
  • rspec (2.12.0)
  • rspec-core (2.12.2)
  • rspec-expectations (2.12.1)
  • rspec-mocks (2.12.1, 2.12.0)
  • rubygems-update (1.8.24)
  • rubyzip (0.9.9)
  • s4t-utils (1.0.4)
  • selenium-webdriver (2.27.2)
  • slop (3.3.3)
  • subexec (0.2.2, 0.0.4)
  • user-choices (1.1.6.1)
  • watir (4.0.2 x86-mingw32, 2.0.4)
  • watir-classic (3.3.0)
  • watir-webdriver (0.6.2)
  • websocket (1.0.6, 1.0.5)
  • win32-api (1.4.8 x86-mingw32)
  • win32-process (0.7.0)
  • win32console (1.3.2 x86-mingw32)
  • win32screenshot (1.0.7)
  • windows-api (0.4.2)
  • windows-pr (1.2.2)
  • xml-simple (1.1.2)
  • yard (0.8.3)
1

1 Answers

2
votes

It's not a bug, it's a feature. :) What you're seeing is an unfortunate side effect of a hack that was introduced in the IE driver to attempt to solve the problem where hovers were not persisted if the physical mouse cursor was within the boundaries of the IE window.

To work around the problem, you have two choices, both involving setting capabilities on the driver when you create it. First, you can revert to the previous behavior by setting the "enablePersistentHover" capability to false. This will stop the flickering as you describe. Second, you could use simulated JavaScript mouse events instead of so-called "native events" by setting the "nativeEvents" capability to false. Obviously, these are exclusive approaches to one another, and shouldn't be used together.