watir-webdriver element.hover, on windows, activates hover but for only a split second

2
votes

I'm using Ruby and Cucumber to functionally test a web application. I am using watir-webdriver to drive the web browser.

My web application has a navigation menu that includes a navigation link which displays a menu of options when hovered over.

I am trying to the watir-webdriver element.hover method to fire the hover event. The version of watir-webdriver in Ruby gems doesn't seem to currently contain this commit to add a hover event to an element however, I monkey patched the element class to add this functionality.

When running my tests on my Mac, using Chrome, everything is fine. The hover even is fired and I am able to click a link in the resulting menu that is displayed.

When I set up the Ruby environment on a colleague's Windows machine however, we do not get the same results. Using Firefox, the hover event does indeed fire, however, only for a split second and then the drop down menu disappears. This causes the test to fail as the following cucumber step tries to click a link that exists on the drop down menu, which no longer exists.

So my question is this:

Does anyone know how, on Windows, when using Cucumber and watir-webdriver, how I can ensure that a hover state remains after calling element.hover?

1
rubywindowsfirefoxwatir-webdriver
No, but you could fire the click event instead. I used to have a problem with that, related to how the mouse moved on the revealed menus. The solution was to just click them. Generally (my opinion here), navigation and menu tests are low value. You could either skip them, run them on a limited number of OS/browser sets, or save that for manual testing. Good luck. – Dave McNulla
True, it is arguable as to whether this test adds much value. But I am trying to introduce a BDD approach to an existing application that has basically zero functional tests. And one of the first, and easiest stories is the hover nav menu. So we're just trying to get things off on the right foot. Thanks for your comments mate. – Aaron Chambers

1 Answers

3
votes

I've seen this (prior to the existence of the .hover method) where the 'hover' state reaction is via a CSS psuedoclass. .hover was introduced to try and provide a way around that. If that is your circumstance and it's not working for you then it might be good to create an issue with the watir-webdriver Github project.

For most stuff that used 'onhover' events in HTML/Javascript it was enough to fire the 'onhover' event against the object and I'm good. This is what most of us did before .hover was added recently. But with CSS based stuff the darned browser seemed to almost instantly 'see' that the actual mouse was not over the object, and reassert the base CSS class's display setting.

So you can find the element in the DOM, you just can't click on it because it's not displayed. (which is a reasonable restriction since no user could click on it in that state)

We've discussed ways around this in the issue that caused element#hover to get added to watir-webdriver. You could try some of the suggestions there, perhaps moving the mouse to the object, but such methods are a bit experimental.

Another solution I have used before is to use execute_script to execute a jquery call that altered the CSS for the object's 'non-hover' class to make it visible, which then allows it to be clicked organically. That's a good solution where the click action isn't causing the system to navigate to a new page.

For instances where the menu item is a simple link, I'd suggest getting the HREF value from the link, and then just using a 'browser.goto' to send the browser there. You can identify the link in the same way you would if you were clicking it, and thus not have to hard-code the link destination in your code, you are just working around the fact that we won't let you click a hidden element (for good reason) If .hover is not working, that would be my first choice if it's a simple link that's going to a href and not fancy client side stuff.