Can someone please take a look at issue 3380?

[Mike Riley]

http://code.google.com/p/selenium/issues/detail?id=3680

I am running into this one daily and have been trying to gather as much info as possible.  Unfortunately it is fairly random as to when it strikes, so I am not sure how to create a reproducible test case.  I am open to suggestions as to how to try and reproduce it.

Mike

[Mike Riley]

Sorry, I meant 3680...

[Jim Evans]

In response to a couple of emails you've sent to webdriver and selenium-users that pointedly mentioned how you're unable to update to a version later than 2.14, I've tried twice to ping you privately to try to discover what, specifically, are the issue(s) that prevent you from moving to a later version. As yet, I've received no response, though I'm sure that's my fault somehow. If the issues preventing you from upgrading are things I can help with, I'll gladly put forth some effort into figuring out how to resolve them. Please feel free to respond off-list to one of my previous emails, or to this one.

--Jim

[Mike Riley]

Sorry that I missed those Jim.  Between working full time and taking classes at ITT I simply have not had much time to get to a lot of E-mails and so rarely look at the GMail stuff, plus it appears I turned for E-mail forwarding on my GMail account.  I just re-enabled it so they will show up at home, so I will see them there now.

I was waiting for 2.21.0 to come out to try and make an attempt at using the newer releases again.

I see your E-mails and will respond to them shortly.

Mike

[Mike Riley]

Jim and I have exchanged a couple of private E-mails about my issue, but I wanted to bring it back to the community here.

I believe that issue 2067 is talking about what is described in the Wiki for the mouseOver issue with IE:
http://code.google.com/p/selenium/wiki/InternetExplorerDriver#Hovering_Over_Elements

As I told Jim, I have verified that this broke in 2.15.0, with 2.14.0 being the last one where this functionality worked.  I would guess that somewhere between 70-90% of all web sites out there need to have this working.  Based on our tracking info for our web site I know that at least 75% of our customers are using one version of IE or the other (we finally got the last one off IE 6 this month).

It is flat out impossible to navigate our web site without being able to hover over a menu element on the page.  So not having a solution to this is a non-starter for us that basically makes Selenium useless.

According to Jim, there is a possible solution, but it would violate the rule of allowing you to use your desktop while a test is running.  Here is what Jim wrote to me:

Regarding IE and mouseover events, I'm frankly confused at how it worked in the first place. Ever since the IE driver implemented the interactions API to support mouse event (and even before, actually), it's been plagued by this particular problem. I suppose it's possible that the Java language bindings moved to using the actual IE driver for WebDriverBackedSelenium's mouse events in 2.15, and that may be why you started seeing the problem there. I honestly don't know; I'm not an expert in the Java bindings and in the history of what exactly landed when with them. Believe me, I'd love to find a solution to the problem, more than you know. If you can ensure that the mouse pointer is outside the bounds of the IE window, that should mitigate the problem.

The technical reason for the problem is that we simulate mouse events by sending Windows messages to the IE window. However, somewhere in IE's event loop, when it receives a mouse event, it calls the Win32 WindowFromPoint() API, which sends a WM_NCHITTEST message to itself to determine where within the window the cursor is. Its drawing layer then repositions elements on the canvas based on the physical mouse pointer. I've tried hooking the WM_NCHITTEST message, but it doesn't seem to do any good. Other alternatives are that we could begin using the SendInput() API, but that would require the IE window to have focus, which it doesn't at the moment. We could manipulate the cursor itself, but that violates the project's "let the user be able to do other things with their machine while a test is running" principle. I'd be interested in your suggestions as to how to solve this particular problem.

Please note, however, that suggesting to simply use JavaScript to simulate the events is something of a non-starter, as native events are generally thought by the project architects to be superior, and with a few notable exceptions (including this scenario), they demonstrably are. However, I'd be willing to implement a "simulated events mode" for the IE driver, but someone else would have to write the JavaScript and integrate it into the existing JavaScript framework of the WebDriver project. I simply don't have the bandwidth to take on that level of effort right now. Now that I think about it, though, I believe the Mouse and Keyboard implementations for the Java bindings are pluggable, so you might be able to create a Mouse implementation at runtime that uses JavaScript rather than native events, so that might be a way to approach it too.

I understand the desire to not violate that rule, and I agree with it as I use that capability doing development myself, however if it comes to a broken WebDriver implementation and not being able to do other things on the same system while a test is running - I choose to fix the WebDriver implementation.  I suggested that the behavior could be modified by having a capability that you can set to affect how it does this.

Since my tests run unattended I don't have the option of controlling where the mouse pointer is located, as he suggested in his first paragraph above.  Right now, in order to support both IE and current Firefox versions I will be forced to run IE on 2.14.0 (which has the issue with IE 9 I outlined in 3680, which is now closed as will not fix) and all other tests on 2.21.0 and higher.

I am hoping we can have a discussion here as to how this can be fixed in the upcoming releases of Selenium.

Thanks.

Mike

[Nathan Dace]

In summary, it looks like there are two possible solutions (correct me if I'm wrong).

• Have the mouse moved away from Internet Explorer window so that the it does not interfere with the WebDriver interactions.
  
• Have WebDriver set focus to Internet Explorer window before each interaction so the SendInput API can be used.
  

For moving the mouse, in C#, you can do something as simple as System.Windows.Forms.Cursor.Position = new System.Drawing.Point(0,0); to move the mouse cursor to the far top left corner of the workspace, off of the browser window.  I'm sure Java would have a similar API that you could fire prior to launching your test script?

Likewise, I know many of my users report to me that IE is not clicking on things, and the root cause usually appears that they user to "doing other things" while the test is running, including moving the IE window, moving the mouse over the browser window etc.  If setting the focus on IE can solve that, then I would be all in favor of it becoming an option for the IE driver.

I wouldn't mind working on a patch for such an implementation, but it would take some time for myself to become familiarized with the WebDriver architecture and how everything jives.

[Mike Riley]

I should mention that I, like a lot of people, am using the Grid2 to access the browser through a remote server.  So any solution would have to work for both local tests using just the Java Client library or a Remote Server situation.

I noticed in 2067 that the last entry mentioned running IE maximized was supposed to help, so I have modified my VMs to run it that way, but I have not yet had the chance to verify if that is a workaround.

Mike

[Mike Riley]

Just thought I would note here that I put an update into 3680, even though it is closed as Will Not Fix.

Based on what I am seeing in the behavior now I suspect the problem is either due to a memory leak or some form of memory corruption that occurs over time.  So quite possibly this is fixed in a later release than 2.14.0.  I figured I should note what I have found in case some finds it via searching the issue list.

Mike

On Tuesday, April 10, 2012 12:08:53 PM UTC-7, Jim Evans wrote:

[Mike Riley]

Jim,

I know this is an old thread, but it is where we discussed the mouseOver issue I was seeing with WebDriverBackedSelenium.  To recap, mouseOver has been broken since 2.15.0 for IE only, so I have been stuck using that version for my RemoteWebDriver server for IE.  I am able to use the current release for other browsers and as my Grid server.

I ran across some breakage with Firefox 13 (Firefox 12 worked fine) that also seems to involve mouseOver.  I have yet to nail that down, but I wanted to report that by changing my routines to using pure WebDriver code I am now able to do mouseOver actions with IE, as I am sure anyone that was using WebDriver has been doing.

I did see the issue reported in 2067 where the mouseOver doesn't persist, which means you can't single step through code doing it, but as long as you let it run the code works fine.  It also fixes the issue I saw with Firefox 13.  So I will be switching to finally using the latest and greatest version of Selenium for IE, probably by next week.

My question to the group is: Is it worth my time trying to figure out a reproducible test case for the issue I saw on Firefox 13 with WebDriverBackedSelenium?  If nobody is fixing such bugs I won't bother.

Here is what I saw:

1. Bring up a popup window
2. Switch to popup window
3. Interact with elements in popup
4. Click on button that causes window to close
5. Switch to original window
6. Do selenium.mouseOver("Xpath string")
7. Wait for menu item to become visible
8. Try to do selenium.click("xpath string") on menu item
   

What ends up happening is that the menu I hover over becomes visible, but when I try and click on the newly visible menu item I see the menu item to the left drop down and it looks like it selects the first item in that menu, but nothing happens.  Since I was working with the second menu the one to my left was the first one, but it also would have been the previous element int he DOM for what I was hovering over, so I am not sure what the behavior would be if I was on say the 3rd menu in the menu bar.

If you put in code to do the same mouseOver and click sequence after this one fails it all works fine.  So only the initial mouseOver + click seems to have this issue.

Again, I saw this in Firefox 13 and not 12, so it may be unique to FF13.  However, I thought I saw something similar once in the IE runs of a different test suite using 2.14.0 as well, but that used different code for handling the popup window.  The IE tests were using WebDriverBackedSelenium methods and the Firefox used (mostly) pure WebDriver methods, so it may be apples and oranges in comparing those two events.  When I changed the IE code to use my library with the WebDriver code I did not see the same menu glitch.  This makes me think it is something wrong in WebDriverBackedSelenium code.

I just don't want to waste time coming up with a reproducible test case if nobody is interested in fixing that area of the code.

Mike

On Tuesday, April 10, 2012 12:08:53 PM UTC-7, Jim Evans wrote:

[Luke Inman-Semerau]

My first opinion is that no, not many would be willing to look into a complex issue with respect to WDBS (hmm, funny the initials end with BS). 

Also my opinion is, if you're looking at the RC code that is causing the issue and it works in straight webdriver code, then you should convert that RC into WD code (you can get the underlying instance of WD from the WDBS instance). It should be 'ok' to mix the two while you're migrating RC to WD (which you should be doing if you are using WDBS).

If you can provide a reproducible test case for just WD code, then please do!

[Mike Riley]

So far the straight WD code is working fine, except for the issue of the hover not persisting as is documented in 2067 (which I see someone says they may have a solution for).

A fix for it would likely be to do the WD steps of creating an Actions instance and the moveToElement().perform(), which would make it simply a wrapper for those WD methods.

In my case all the locators are XPath, so I don't have to figure out what locator type is being used to know which By method to use.

Right now I have other issues to deal with, so I will have to put this off.  I might file an issue as a placeholder though.  I will verify it is still an issue with 2.25.0 before I do that though.

Mike