I recently made a change to IEDriverServer.exe that changes how elements are clicked when using WebElement.click(). It's possible that this change may break some cases. I need help in figuring out if I've broken it, because I can't test every edge case out there. To that end, I'm asking for your help. Here's what I would like folks to do.
1. Pick up IEDriverServer.exe 2.32.3.11 from
http://selenium.googlecode.com/git/cpp/prebuilt/Win32/Release2. Run your tests with that version of IEDriverServer.exe.
If you run into situations where the IE driver does not click an element when you're using WebElement.click(), I want to know about it. Now, there are some caveats to this.
- If your code also fails with 2.32.3.0 (the version available at http://code.google.com/p/selenium/downloads/list), I don't care[1].
- If your code uses the Advanced User Interactions API (the "Actions" class in Java and .NET) to click the element, and it fails, I don't care[2].
- If you are unwilling to provide a full test case with a full HTML page that demonstrates the issue, I don't care[3].
I'd like to try to verify where this change breaks stuff before pushing it to wide distribution on the main downloads page, so if you're willing to help out, pick up the prebuilt binary, and give it a shot.
[1] Actually, I do care, but that means it was broken before, and is broken now, so my changes didn't break it further.
[2] Again, I really do care, but the changes I've made shouldn't be touching this code path, so I want to fix the WebElement.click() case first.
[3] Here again, I do care, but there's nothing I can do about it if I can't repro it. I've already tested most of the common cases, but there's no way I can know what all of the edge cases are, and I need pages that hit those corner cases. Also, there is no "unable to provide a full test case," only "unwilling to." If your app is hosted internally and you can't give access to it, that just means you're unwilling to do the work to create a public page that repros the problem.