MSIE: clicking a button sometimes selects it

[Mikhail Ramendik]

Hello,

I am facing a strange problem here. I am using Selenium 2.53.1 Java, MSIE driver 2.53.1.

When I use click() on a button, sometimes - but NOT every time - the button is not clicked. It is instead shown as "selected",as if one were to Tab to this button.

I can work around it by a second click (handling a failure in case the first click works), but this still looks pretty strange.

This was not happening until today. But the only thing I changed was adding a cache clearing before running MSIE. The clearing process does complete before the driver is initialized for MSIE. I do it by: 

      Runtime.getRuntime().exec("RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 255");

The reason I added it is because if the cache is not cleared, the UI under testing sometimes fails. And I can't see how this would affect the operation of click(), as the process is completed before the driver is initialized.

I would appreciate any hints about resolving this.

Yours, Mikhail Ramendik

[Ahmet OZKESEK]

Hi,

It is really interesting.

What about .sendKeys(Keys.ENTER) instead of .click()?

AO,

[Jim Evans]

First blog post I ever wrote. Still applicable.

http://jimevansmusic.blogspot.com/2012/06/whats-wrong-with-internet-explorer.html

Possible mitigations enumerated in a follow up post.

http://jimevansmusic.blogspot.com/2013/01/revisiting-native-events-in-ie-driver.html

Jim Evans
Maintainer, Internet Explorer Driver,
Selenium Project

[Ahmet OZKESEK]

Great. Thank you Jim.

AO,

[Mikhail Ramendik]

Thank you very much!

Based on what I read at your links, I have set the "requireWindowFocus" capability and then ensured that the machine is untouched and the window stays in focus. And the issue has apparently disappeared.

As an aside, your call to Microsoft has apparently been answered with their Edge driver. But we're not really using Windows 10 on our test VMs, and besides, Edge testing would not really cover MSIE users. So we'll probably go on using the MSIE driver.

[Mikhail Ramendik]

Sadly, upon another run the issue still seems to happen sometimes.

Is there any additional way to ensure the window is indeed in focus? Also,  would it be safer to use Actions.click() rather than WebElement.click() ?

I am thinking of overriding WebElement.click() just for MSIE. But as I can't typecast a superclass into a subclass, the only way I can think ofis to create a new class that has a WebElement as a field, and passes all ofthe calls in the WebElement interface tothe object in that field - except click(). And then make a subclass of the IE driver and override findElement and findElements to return instances of this new class.But this sounds lie an awful lot of work...

[Jim Evans]

A general rule of software development: It's exceedingly difficult to fix what one cannot reproduce. If you have s case that consistently reproduces the issue, that would be useful in diagnosing the problem, perhaps leading to a fix.

[Mikhail Ramendik]

You are right, thanks.

I have done some investigation. Actually,  the "requireWindowFocus" capability does fix the original issue. The original issue is that clicks fail intermittently.

With  the "requireWindowFocus" capability, clicks consistently succeed when I run the test on a VM with a Remote Desktop connection. I ran a 10x loop of the entire test suite just for MSIE, and it all worked.

Unfortunately, if I disconnect the Remote Desktop connection, with the "requireWindowFocus" capability still enabled, clocks consistently, repeatably fail - I get an exception on the very first call to WebElement.click()

And I really do need this test suite to run unattended, using Jenkins. Using another VM to keep a Remote Desktop connection going is theoretically possible, but probably hard to maintain. 

Is there any way to get around this problem? 

[Mikhail Ramendik]

Upon further investigation:

- It appears that without the "requireWindowFocus" capability clicks still always work IF the MSIE window has focus, whether there is a remote desktop connection or not

- It appears that, if the machine is untouched (including the case when the remote desktop connection is disconnected), once the window is focused, it stays focused for the rest of the test suite until one closes the driver - at which point the window is closed as expected. There is a point of possible failure, though - when the driver starts MSIE, MSIE sometimes does not get focus.This only happened once in a significant number of runs, so I'm not sure if I can reproduce it.

- It appears that, unfortunately, even without "requireWindowFocus" I get consistent failures (on the second if not the first click) if I run MSIE tests under Jenkins slave as a Windows service. Is this simply impossible? 

- Also it turns out I have described the failure wrongly - the WebElement.click() method simply does not cause a click. And then I get an exception because the code is looking for a page that appears after the click. Which is of course not there.

So - trying to guess here - I might just need to run the Jenkins slave in a displayed way, not as a Windows service, and also somehow to ensure that MSIE gets focus every time? Is there a way for me to ensure MSIE gets focus? I tried VBscript but it fails when there is no Remote Desktop connection. Or do I need to do something else entirely?

(Or should MSIE always get focus, and what I encountered was a random glitch?)

[Harry King]

Mikhail,

I'd suggest avoiding running the Jenkins agent as a service, as IE expects a desktop and won't play nicely, as you have discussed.  Instead, start the slave using the Java Web Start option, download slave.jar from Jenkins and setup a simple batch script that runs the jar when the account logs in.  Then set Windows up to auto login as that account. Hopefully this should help you out.

[Mikhail Ramendik]

Thanks for the suggestion!

I am currently trying autostart with the javaws command, which does not require me to work out where the correct slave.jar file is etc. If I can't make it reliably autostart without getting lost in Java or firewall warnings, slave.jar is the next option on the table.