Click() vs SendKeys(Keys.Enter)

[Nathan Dace]

I'm using C# WebDriver 2.20.

In IE, I've been encountering a lot of "misclicks" when using Click(),
in that it appears that the link is clicked, but nothing happens. To
fix this, I've switched to using SendKeys(Keys.Enter) wherever
possible, which has solved my issue.

However, I've noticed that if I'm clicking a link that opens a new
browser window, the test does not automatically wait for the new
browser window to finish loading.

If I use Click(), then WebDriver waits for the new window to load
before continuing.

Is there any method call that is exposed by WebDriver that allows for
test to synchronize with page loads, or in this case, with new browser
window loads?

[Jim Evans]

In a word, no.

The IE browser uses native events for user interactions, which implies that they are asynchronous. For .Click(), we make a "best effort" to wait for the page to load. If you're going to step outside of that best effort that the library provides you by using .SendKeys() instead, you'll need to implement synchronization on your own. For the .NET bindings, this usually means adding a reference to WebDriver.Support.dll and using the WebDriverWait class.

As an aside, if you're find that the wait behavior of .Click() is desirable, but you're having issues with it, the best way you can help is to provide a complete reproduction case, including a test page (or link to a public URL) to run your code against. Additionally, I'm always extremely grateful for patches, if you come up with a way to fix the issues you're seeing.

--Jim

[Nathan Dace]

Thanks for the reply. I think the misclick issue is more of a user issue, as it seems to happen when they start a test and then move or resize windows as the script is running.

I implemented a standard wait wrapper around the send keys where it's used for "clicking" and it appeared to solve the issue.

I'll keep an eye out for a reproducible failure path for a misclick, as I know otherwise these type of issues can be difficult to work on.

Thanks!

[Nathan Dace]