I've taken a look at the IEThreadElement code.
The getLocationWhenScrolledIntoView method tests if the left upper border of the
element is visible. Only if not, it scrolls it into the view.
The point clicked on the element is the center. But in contrast to the upper left
corner, the center is not tested to be within the viewport.

I think the problem could be fixed if the element is clicked in the center of the
visible part of the element. And looking deeper into the code... in getLocation...
TADAAA:

// TODO(simon): we should clip the size returned to the viewport

That seems to be a good idea and maybe fixes the problem.
But I'm no C++ programmer and we're talking about InternetExplorer so your code might
also be correct and the real reason is the bad weather.

OK. I tried to get a debug/dev environment running to fix it myself but I have to
give up, sorry.

The problem here isn't the TODO (fixing that will simply return an error when you try

to click something), but is that if the element is scrolled into view and displayed,
we 
assume that the centre is displayed.  What needs adding is code which explicitly checks

whether the point we're about to click is displayed, and if not, scrolls.

Broken on IE, Firefox, Chrome.

Although I think it's more natural to click on the center of the visible part instead
of scrolling to the center of the element first, any fix is appreciated.

If it's broken on IE, Firefox, and Chrome, are you talking about a central piece of
code that needs to fixed - something you can point out?

Any known workarounds for the problem?
I would love to use webdriver but I'm afraid I can't use it if the clicks are not
reliable.

I just ran into something worst...clicking scrolls but the scrolling leads to clicking
the wrong thing or nothing at all.  I am seeing this when trying to click dynamic menu,
it scrolls to the element, enough it is visible, and can click the wrong element. 
In another case, there is dojo dialogbox, which open in the center of screen so always
visible.  But clicking a button, want to scroll to it leading to clicking nothing.
 I see the page scrolling.  I am using Firefox 3.5 and 3.6 and selenium 2.0a5.

can confirm my project is getting the same behavior - if button is visible on form the
click event is executed, but not if the click is supposed to be on a node which is
not visible. using Firefox / IE and 2.0a5 Se with WebDriver.

I checked the latest release (2.0a6) with the testcase provided in my initial comment
and it still fails.

I fixed this issue in IE by changing the driver to verify the middle of the element
is visible instead of the top-left. This could still cause issues if the element you
want to click is so large that even if moved to the top it's middle is not in the view
port. That seems like an unlikely case to me though.

Interestingly I only have issue with clicking element on scrolling page on Windows but
not Linux. The workaround that I have deployed is to use javascript click rather than
native click event that webdriver provides.

I can recreate it with Internet Explorer only anyway (at least with the testcase linked
above). @nhuttan.oz Did you observe it in other browsers on Windows as well?

@steffen I observed it in Firefox 3 on Windows 7 using selenium-java-2.0a2

i also managed to reproduce the issue on firefox 3.6 on windows server 2008.

I managed to build a testcase for the bug on firefox. I think it is not exactly the
same as the internet explorer bug:

Open the attached html-file with the firefox driver, and let it click on the link.

It will not work, due to the line wrapping. 
I suspect that it tries to click on the center of the bounding box of the link, which
is actually not part of the link.

Christoph, you are correct. I can recreate the mentioned error too. I included it in
the testcase above and updated the JUnit code.

The testcase proves that this one is not dependent on the position relative to the
viewport. That's why I created an additional test method for it. I suggest it should
be filed as a separate issue for all browsers (I tested FF 3.6 and IE 8).

Speaking of browsers, I still can't provide a valid testcase for Firefox and the viewport
problem.

in wrappedElement.js (webDrive.xpi, selenium 2.0a7)

 if (this.enableNativeEvents && nativeEvents && node && useNativeClick && thmgr_cls)
{
    Logger.dumpn("Using native events for click");
    var loc = Utils.getLocationOnceScrolledIntoView(element);
    var x = loc.x + (loc.width ? loc.width / 2 : 0);
    var y = loc.y + (loc.height ? loc.height / 2 : 0);
...

This code call the method element.getBoundingClientRect().
It works well with block elements like "div".
But to inline elements like "a", how about using "getClientRects" ? 

Thanks

excellent suggestion, temp.you, I just tried it and it works!

I created a new issue for this problem: 1020
http://code.google.com/p/selenium/issues/detail?id=1020

Issue 1020 should be the same as issue 835:
http://code.google.com/p/selenium/issues/detail?id=835

Issue 835 indicates it works with IE, while issue 1020 actually does not work with IE8.

Issue 1190 has been merged into this issue.

Issue 1186 has been merged into this issue.

Issue 707 has been merged into this issue.

simple workaround that I found working: you can use javascript call from RemoteWebDriber
to change window size or move viewport, so that link becomes clickable.
Eg. 
driver.executeScript("window.moveTo(0,0); window.resizeTo(screen.width,screen.height);");

Not sure if this issue is related, but it seems very similar:
http://stackoverflow.com/questions/5574802/selenium-2-0b3-ie-webdriver-click-not-firing

So basically Click() on an element fails occasionally and unpredictably if the browser
does not have focus.

I don't think that is the same bug. I have seen webdriver scroll to an element and actually
scroll further then it should (pixel position of element incorrectly calculated). Afterwards,
trying to interact with another element just off the edge of the screen that would
have been visible if webdriver scrolled to the correct pixel position for the first
element causes an error since it thinks its visible but it is not.

I'm not sure if this is the same bug or not, but I've been having a very similar problem.
 Sometimes, for no apparent reason, an element.Click() event will have no effect. 
However, element.SendKeys() will work perfectly on that same element instance.

I've noticed that, whenever this occurs, the browser scrolls down first, presumably
so that the element will be on the screen.  However, in my case, the entire element
is visible when this happens.  Instead, what happens is that only the top portion of
the button is on the screen initially.  Then, when Click() is called, the browser scrolls
down so that th button is 100% visible.  Then, nothing happens.  The click doesn't
actually take place.  No hanging or errors, just skipped.

I've been in debug mode trying to see if there's any possible way to get the button
to click, aside from using SendKeys().  So far, nothing.

Also, I have the browser maximized when the test first starts.  While I'm sure that
reduces the risk of this happening, it doesn't eliminate it.  Even when the browser
is maximized, it's not uncommon for there to be vertical scrolling, and for an element
to be only partially visible at the bottom of the viewport.

Has there been any recent activity on this front that anyone knows of?  If not, would
it be possible for me to check to see whether or not Click() actually succeeded?  It
doesn't have a return value and it doesn't throw any exceptions on failure as far as
I can tell.  But if I can capture that somehow, then I could at least create a workaround
that would call SendKeys(" ") if the Click() fails.

I've just discovered that the SendKeys("\n") workaround doesn't work on checkboxes (using
spacebar didn't work either).  At present I can't think of any other workarounds to
get that box checked.

Clicking elements on the border or outside the viewport works in the latest ChromeDriver.
Removing Chrome label...

I tested with latest releases and couldn't recreate the problem on Internet Explorer
with any release >= 2.0.0 (but not including 2.0a6).
Case closed for IE it seems.

I believe this is fixed in Firefox as well, since we now have code to scroll the clicked
location into view.

I have this problem in IE8 and Selenium Standalone Server 2.19 on XP. Can't click on
link which is partly out of ie view area (at the right side of browser under scroll
bar).

But the more interesting that following code doesn't work either:

                Actions builder = new Actions( getWD() );
                Action hover = builder
                        .moveToElement( _obj, 5, 5 )
                        .build();
                hover.perform();

(5,5) point of element is visible.

click is performed fine if I manually scroll horizontal view to "logout"

Let me clarify the problem I am having in IE9, WebDriver v2.21.  The following is a
sampling of the approaches I have taken.  I have tried many variations of each!

--- driver.findElement(By.xpath(seleniumLocator)).click()
     Often has no effect

--- new Actions(driver).moveToElement(element).clickAndHold().moveByOffset(1,1).release().perform()
(and MANY variants of same)
     Sometimes has no effect

--- driver.findElement(By.xpath(seleniumLocator)).sendKeys(Keys.ENTER)
     Sometimes triggers the stale element exception and
     sometimes does nothing but prints "We don't have focus on element." to the console

--- ((JavascriptExecutor) driver).executeScript("return arguments[0].click()", element)
     By far the most successful approach I have used, as it always successfully clicks
the element.  BUT it does not return when the click triggers a modal dialog.  (The
other approaches detailed above do not have that problem - on the occasions that they
successfully click the element, they return even when the nodal dialog is triggered.)

I have not tried calling WebElement.submit(), because the problem occurs with many
elements that are not part of a form

Note that I experience this erratic behavior with many elements.  Things that most
or all of those elements have in common:
   They do NOT wrap the screen
   They do NOT need to be scrolled into view
   They do NOT have odd viewport characteristics
   They are mostly incredibly simple elements, for instance:
  <input type="submit" value="Login" name="Login" id="Login" class="loginButton">

Things that all observed failures have in common:
   All fail in IE9 (have not tried another version, but that's a moot point - I have
to support IE9
   The browser is zoomed at 100%
   The browser's being maximized or not is not a factor
   Timing is not an issue - it happens just as often when stepping through the code
as not

I have done more than a little research, and have tried pretty much every approach
that is purported to work.  However, I have yet to find an approach that works consistently.
Does anyone know of a rock-solid workaround?   

hi jeffrey, 
i am facing the same issue. Did you get any solution for the same.
Thanks in advance

@jeffreyablaze, without a test case there's not a lot we could do. Please provide an
HTML snippet and test code in the language of your choice that reproduces your problem.
Also, please open a new issue for this.

Same here on MacOS with Chrome, a possible clue was that the link was partially hidden
behind the address bar that appears at the bottom of the Chrome window.

Hi,

I have the same problem with Firefox, the radio button is under the drop down. Please
let me know if you have any solution.

Thank you in advance,

Hi, 

    I am facing a similar issue.a button is outside the view area and when i scroll
down the button is seen.Is is possible to click on the button without having to scroll?

Thanks,
Sanam

I've found, on MacOS (10.8) with Chrome, that switching "Show scroll bars" to Always
(in System Preferences -> General) seems to fix the occurrences of this problem I was
seeing.

Presumably the problem was caused by the fact that the scroll bar would magically appear
over some page content when the 'click' occurred near the edge of the window, where
as changing it to always show causes a specific area to be allocated for the scroll
bar which doesn't have any content behind it (and hence is never clicked).