The phenomenon at first made us suspect there were possible race conditions in our JavaScript code. Were we accidentally clearing/hiding elements before WebDriver could reach them? Was the web browser loading multiple times and clearing out the original state? Or was it an issue in Selenium 2, since it attempts to calculate the center position of the element, scroll into view, and then move the mouse cursor to the center of the element (see http://www.google.com/codesearch#2tHw6m3DZzo/trunk/javascript/atoms/dom.js). You can look at how the Windows driver's mouseMove is implemented here:
http://www.google.com/codesearch#2tHw6m3DZzo/trunk/cpp/webdriver-interactions/interactions.cpp
It turns out that hover states for Windows in Selenium 2 are just problematic right now. You can even see inside the Selenium 2 test suite that hover states are not skipped: for Windows-based systems:
http://www.google.com/codesearch#2tHw6m3DZzo/trunk/java/client/test/org/openqa/selenium/RenderedWebElementTest.java&q=2067%20package:http://selenium\.googlecode\.com
if (!supportsHover()) {
System.out.println("Skipping hover test: Hover is very short-lived on Windows. Issue 2067.");
return;
}
The full bug report is here:
http://code.google.com/p/selenium/issues/detail?id=2067
In Selenium v2.15.0, even the Internet Explorer wiki was updated to remind people that hover states (using mousemove) have issues:
http://code.google.com/p/selenium/source/diff?spec=svn14947&r=14947&format=side&path=/wiki/InternetExplorerDriver.wiki
The workaround seems to be generating your own synthetic events:
$('#myelem').trigger('mouseenter');
No comments:
Post a Comment