Please try to create a low level test case where this is reproducible to some degree.
If not, include a link to the site you were testing, with some information on the elements
in question.

We have noticed the same problem for the application we are testing, somehow it seems
hard to reproduce. Some of our computers running the testcode seem to miss to click
almost every time (without fail) while others only occasionally fail. The most common
time of error is when debugging our code with Netbeans. I don't know if this is just
a coincidence or if it could be interfering somehow.
our testing environment:
Ie 8, selenium-java-2.0b2 + selenium-server-standalone-2.0b2,WinXP

I believe that if you find a site with a checkbox and go to it with IE you will encounter
the same issue. it happens almost all the time with IE driver on checkboxes.
I have tried it in a number of internal applications to which I can not refer you.
P.S
the IE driver also gives me issues with clicking on some links from time to time.
should the link have a specific structure (HTML build, attributes etc.) so clicking
will work? or should it simply be an <a> tag. FF does click it successfully.

the problem I face exists on windows xp with IE8,
I have to mention that on windows 7 with IE8 it works fine.

There are a number of tests in the unit tests for the project that exercise the code
for selecting checkboxes, and these indicate no problems in IE. Therefore, it is not
a universal problem with every checkbox. Again, we will need a page that reproduces
the problem consistently in order to debug it. Note that it does not need to be a page
of the "internal application" itself; a simple html page that you have written yourself
will suffice, as long as it reproduces the problem

We have backed our codebase to Selenium alpha7 and have seen this behaviour there also.
It seems to some javascript that goes bad and all clicks and commands that post data
stops working. We had a stable test that always failed but we have rewritten the code
since then. But one issue that caused this was maximizing the internet explorer window
when it was already maximized.

Closing issue with status NeedsClarification for > 2 months.

Just wanted to mention a workaround for this - if a particular element in IE8 with WinXP
resists being clicked with WebDriver's Click() method, code like this usually works
for me (in C#):

// Use SendKeys() instead of Click() to perform the click
driver.FindElement(By.Name("foo")).SendKeys(Keys.Enter);

Then, since SendKeys returns immediately, I use WebDriverWait to spin until the browser
is ready to continue.

The failed Click() behavior still happens consistently for me when trying to click
form submit buttons, in this configuration:

selenium-dotnet-2.0.0
Windows XP
IE8

I also am experiencing this, using SeleniumDotNet-2.0RC. When Selenium is only using
the IE browser, the clicks always work. However when my test assembly has multiple
browsers open (Chrome + Firefox), sometimes the IE clicks do not trigger the javascript
client validation they are supposed to. The clicks always work on Chrome and FF. 

Thanks to billa for the workaround. I have created an Extension method that seems to
work when the .Click() method fails to work in IE:


        public static void ForceClick(this IWebElement element, IWebDriver browser)
        {
            if (typeof(InternetExplorerDriver) == browser.GetType())
            {
                element.SendKeys(Keys.Enter);
            }
            else
            {
                element.Click();
            }
        }

I am using IE on Windows 7 via RemoteWebDriver and I occasionally get StaleReferenceElementExceptions
from time to time. The funny thing is this often occurs between two lines of code like:
WebElement el = driver.findElement(By.id("abc"));
String text = el.getText();

I mean, between these two lines of code, there are only a few milli seconds. How can
that be, that the WebElement isn't valid any long on the second line? That makes it
impossible to write stable tests with InternetExplorer. Very sad though...