Click button does not work after upgrade to selenium 2.48.0

[Tset-Noitamotua]

Doing test automation on a Ember.js web application:
I have a button which is covered by a <div> with a cooky notification. It looks something like this:

With Selenium 2.47.1 clicking on that button works as expected in Firefox.
With Selenium 2.48.0 clicking this button does not work in Firefox, although there is no exception or error. It's like selenium thinks that the click worked properly but actually the click had no effect. Here the Robot Framework log:

The structure of HTML is something like this:

<header>...</header>
<main>
  <div>
    ::before
    <form>
      <button>Last check</button>
    </form>
  ::after
  </div>
</main>
<div>
  <div class="cookie-notification">
    ::before
    <a href="http://...">Close</a>
    ::after
  </div>
</div>

Just for comparison - executing the same click with Selenium 2.47.1 in Chrome results in a WebDriverException:

Traceback (most recent call last):
  File "<string>", line 2, in click_button
  File "C:\Python27\lib\site-packages\Selenium2Library\keywords\keywordgroup.py", line 15, in _run_on_failure_decorator
    return method(*args, **kwargs)
  File "C:\Python27\lib\site-packages\Selenium2Library\keywords\_formelement.py", line 316, in click_button
    element.click()
  File "C:\Python27\lib\site-packages\selenium\webdriver\remote\webelement.py", line 69, in click
    self._execute(Command.CLICK_ELEMENT)
  File "C:\Python27\lib\site-packages\selenium\webdriver\remote\webelement.py", line 448, in _execute
    return self._parent.execute(command, params)
  File "C:\Python27\lib\site-packages\Selenium2Library\webdrivermonkeypatches.py", line 11, in execute
    result = self._base_execute(driver_command, params)
  File "C:\Python27\lib\site-packages\selenium\webdriver\remote\webdriver.py", line 196, in execute
    self.error_handler.check_response(response)
  File "C:\Python27\lib\site-packages\selenium\webdriver\remote\errorhandler.py", line 181, in check_response
    raise exception_class(message, screen, stacktrace)

System configuration I:

• Microsoft Windows 7 64 bit
• Firefox 41.0.2
• Selenium 2.47.1
• selenium2library 1.7.4
• Robot Framework 2.9.2
  ==> click <button> works

System configuration II:

• same as configuration I but
• Google Ghrome Version 46.0.2490.80 m
  ==> click <button> does not work, WebDriverException

System configuration III:

• same as configuration I but
• Selenium 2.48.0
  ==> click <button> does not work, no error/exception

[davehunt]

This is due to the change 0eec81d, which makes Selenium more closely resemble a user when interacting with elements. You could try scrolling the element into view before attempting to click it. /cc @barancev

[costag1982]

I had the exact same issue yesterday and I did indeed try scrolling to the element first before clicking and it still didn't work. I changed my webdriver to Chrome and the test passed which then led me to believe this issue was created in the recent update.

[Tset-Noitamotua]

There is no possibility to scroll down in my case. My solution was to downgrade to Selenium 2.47.1

[barancev]

I wonder how a real user can click this button if it can't be scrolled into view?

[vveliev]

I think I have a similar issue ...
#1166

[Tset-Noitamotua]

@barancev
Real user can close the cooky notification by clicking the X on the right. The button is then uncovered and can be clicked. For my automated test I need to implement extra logic to handle this.

[Tset-Noitamotua]

@davehunt
Thanks for the hint on 0eec81d. Does that mean that by me descriped behavier is intended and should be understood as a feature?

If so, then I would suggest to give the user a notification or exception like the one of Chrome webdriver: Element is not clickable at point (x, y). Other element would receive the click: <div class="classname">...</div>. This would make it easier for the user to understand what happened.

[phoenix384]

This is no feature and it made us roll back to 2.47 also.
The argument "simulating what the user can do" is overused to the detriment of ease of use.
Depending on the overlapping element a real user could just scroll the page a bit or close the overlapping element. At least the scrolling would be something FirefoxDriver should be doing automatically after this change.
Or how should I guess beforehand when a page is accidently scrolled to the wrong position?

This behaviour in ChromeDriver is annoying, but in Firefox it is now even worse since it simply clicks and nothing happens instead of at least throwing an exception like ChromeDriver.
With webelement.click() I expect the click to go to the WebElement and not to the position of the WebElement. If I explicitly want to click its position I can achieve that with the Actions class.

If you make such changes you should provide a possibility to disable this new behaviour for compatibility purposes.

[barancev]

If you want to "click" an element that is hidden behind some other element you can use JavascriptExecutor. It is close to impossible to implement autoscrolling that could resolve overlapping.

[malligr8]

Hi,

Element is not clickable at (x,y) co-ordinate seems to be an old Issue
2766, which we have solution. I have the same problem and i tried below
solution.

((JavascriptExecutor)
driver).executeScript("arguments[0].scrollIntoView(true);", element);

More reliable solution would be

Waitfor the Element to untill it was stable by any of the
Expectedconditions and then do scroll on weblement as below.
((JavascriptExecutor)
driver).executeScript("arguments[0].scrollIntoView(true);", element);

Regards
Malli

On Fri, Oct 30, 2015 at 8:28 PM, Alexei Barantsev notifications@github.com
wrote:

If you want to "click" an element that is hidden behind some other element
you can use JavascriptExecutor. It is close to impossible to implement
autoscrolling that could resolve overlapping.

—
Reply to this email directly or view it on GitHub
#1202 (comment)
.

[davehunt]

I'm also seeing this, where an element is temporarily over the target element. It took too long for me to confirm exactly what was going on (although I suspected it almost immediately). The patch in #1211 helped with my confirmation. In my case, I've decided that the proper solution would be for the application under test to give a suitable indication that the obstructing element is not displayed. Due to the initial state of this element not being displayed, there's no appropriate waits that I can use - I even experimented with executing JavaScript with a MutationObserver. The project in question is not actively being developed, so I'll open an issue against it, but likely just add a sleep to my test suite. If anyone's interested, here's how to reproduce my issue:

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.wait import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Firefox()
wait = WebDriverWait(driver, 10)
driver.get("http://beta.123done.org/")
main_window = driver.current_window_handle
for i in range(5):
    wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, "#signinhere button"))).click()
    wait.until(lambda d: len(d.window_handles) > 1)
    driver.switch_to.window(list(filter(lambda w: w != main_window, driver.window_handles))[0])
    wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, "#authentication_email"))).send_keys("webqabrowserid@aol.com")
    wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, "p.submit button.isStart"))).click()
    wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, "#authentication_password"))).send_keys("dsadadawdsda")
    submit = wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, "p.submit button.isTransitionToSecondary"))).click()
    assert wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, "#cannot_authenticate"))).text == "Password incorrect"
    driver.close()
    driver.switch_to.window(main_window)
driver.quit()

Thanks to @p0deje for his patch in #1211 and also to @barancev who was able to confirm that he saw this issue whilst I was investigating it.