Click button does not work after upgrade to selenium 2.48.0

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

[jimevans]

A quick refresher course in element scrolling and the intent of the WebDriver API might be instructive. It is now, and always has been, the intent of the WebDriver API to mimic user interaction with a page as closely as possible. That means that if an element is obscured by another element, it can’t be clicked on until it is (1) scrolled into the view port, and (2) scrolled to no longer be obscured by other elements.

The first condition is handled by most driver implementations by use of the JavaScript scrollIntoView function. This function aligns the scrolled element to either the top or bottom of the view port, depending on the value of a boolean argument. Because some modern sites have fixed header or footer elements that float atop the z-order, the driver gives you the option of which alignment to use via the elementScrollBehavior capability. Note carefully that the JavaScript scrollIntoView function does not provide a mechanism for scrolling to the middle of the view port. It would be nice if it did so, but that’s a matter for standards bodies and browser vendors. Anyone who would like to take a crack at an implementation that scrolls to the center is welcome to submit a pull request.

As for the change in behavior on click, modifying the Firefox driver in this way aligns its behavior with other drivers. In the case of the Chrome driver, the click method throws an exception if the target element is overlapped by another. The IE driver (when native events are enabled) will happily click on the topmost element, which is arguably worse. As of 2.49, the Firefox driver’s behavior should now align with the Chrome implementation. Consistent behavior is better than inconsistent. The fact that in the past it was possible to click on an obscured element with the Firefox driver was unintended, and was a bug in the Firefox implementation, pure and simple.

[lukeis]

@Cyberia-- the ability to disable the error in firefox was added in 2.52 with this ab994066135f81b43d6ebed93bb398e7c7d064c1 see the first file changed for the capability name to disable it.

Since this issue is closed and consistently attracting new commentors, i’m going to lock it. Please log new issues with reproducible test cases if you have a bug. If you are asking a question or need a clarification on something, please do not log a new issue and email the selenium-users google group.